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ABSTRACT 


Tlu! eolifui’enpo on t'ho Conipnctng Environment for 
Matheitmtleal Software, held in J'aaatlenn, California 
on July 2‘)-'U, 1981, waa coaponaorcd by the Jet 
I’ropnlalon Laboratory and the Special intereat Group 
on Numericnl Muthematlca of the ASBoelatlon for Com- 
pviting Machinery (ACM-SIGNl'M) . The conference pro- 
vided a sequel to two previous SIGNUH conferences 


hold in Tasadena in 197A and 1978, Topcla included 
Boftwaro tools, Vortran atundarda activity, and 
features of languagoa, operating syatems, and hard- 
war,e that are important for the devolopinent , testing, 
and maintenance of mathematical software. This 
publication includes extended abatrncta of the papers 
presented at the. conference, 
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CONFERDICB OVERVIEW 
FRED T. KROGK, Corfaranos Chairman 


Tha aathaBatloal aortwara oomaunity baa aa 
its primary goal tha davalopmant of high quality 
toola for tha aolution of a wida variety of 
matbematioal problama. Tha davalopmant of auoh 
tools la auhanoad by otbap tools; both hardware 
and software, which provide a hospitable computing 
environment. Unfortunately, our environmental 
needs are not well known to the computing 
ooumunlty at large. Under the able leadership of 
C.L. Lawson, JPL and ACH-SIGHUH have previously 
sponsored two conferences related to this one; 
■Workshop on Fortran P.'uprooessors for Numerical 
software* in 1974, and *Conference on the 
Programming Environment for Development of 
Numerical Software* in 1978. These conferences 
have provided a unique forum for those Interested 
in the environment for tha development and use 
of mathematical software. 

In tha early days of computing there was an 
emphasis on the needs of those who were solving 
mathematical problems. But the perception that 
mathematical computation is only a small part of 
the marketplace and the fact that the needs of 
those engaged in numerical computation are not 
well known has led to considering those needs as 
little more than an afterthought. Recent advances 
in software and hardware technology are making it 
economical to create computing environments 
appropriate for specialized applications. The 
implementation of a small specialized language or 
operating system environment is now a small enough 
Job that significant experimental environments can 
be designed and Implemented. Large vector and 
array processors are being designed and built with 
numerical computation aa the primary or only 
application. At the microprocessor level we are 
getting arithmetic units superior to what we are 
used to on general purpose computers. The 
computing envlroiusent for mathematical software is 
changing for the better. This conference provides 
a view of those changes. 

Fortran still appears to be the language of 
choice for scientific and engineering computation. 
Interchange between the fortran standards 
committee, Z3J3, and the mathematical software 
community baa proven valuable to both at previous 
conferences in this aeries. Continuing this 
tradition of interaction, talks by Adams, 
Meissner, Wilson, Wilkens, and Smith from X3J3 
give an Idea of the substantial changes that are 
being planned for Fortran. Some of these new 
features are being introduced primarily to meet 
needs in numerical computing. 

Thera has been a lot of recent work on 
Fortran programming environments. Miller gives an 
overview of three of these and describes some 
current work. Lucas examines the environment from 
the vinwpoict of one supporting the use of 
mathematical software in solving scientific and 
erglneerlng problems. There is considerable 
overlap between statistical and mathematical 
software. But there has been considerably more 
emphasis on canned packages for the 
unsophisticated user in the former case. Ryan 
describes several statistical packages, where the 
emphasis has been on their packaging. He expects 
benefits from future interaction with computer 
science. 


Amano, Chiba, Machida, and Haada in ona 
paper, and Gaffney in another, dtacriba ayatama 
that make it easier for uaers of mathematical 
software to find the software appropriate for 
their needs. 

At the 1978 conference, Kahan spoke on 
speniflcatlons for a proposed floating-point 
arithmetic standard, and Hull spoke on desirable 
oharaoteristloB for floating-point and elementary 
funotlons. Kahan's ideas have led to a proposed 
IEEE standard for floating-point. This proposad 
standard is currently available on one 
mloroprooessor chip, and there are strong 
indications thst several others will be marketed 
soon. Expanding on the theme of floating-point 
arithmetic, Kahan dlscuases the programming 
environment's contribution to program robustness. 
Hull's IdesB have also progressed to the point of 
being implemented. He describes the capabilities 
of his hardware unit here. 

In these abstracts, Ginsberg gives a 
blbllo,?raphy on suporcomputers. In h;)s talk he 
reviews perforriance comparisons for supercomputers 
and the more oouventional type. Extensible 
languages have buen found useful in designlrj; the 
uasr intorraoe for solving partial differential 
equations by Delves. He describes this work which 
was done in an ALGOL 68 environment. 

in the 1976 conference, Webb Hiller proposed 
the Initiation of a collaborative effort to create 
a better programmlrig environment for the Fortran 
programmer. His proposed *T00LPACK* is now a 
project involving several institutions. Osterwell 
describes the TOOLPACK project. Mehlsohau 
presents a commercial software tool collection 
available from SOFTOOL Corporation. Krogh and 
Snyder describe a support environment for software 
tools that is compatible with the requirements of 
the TOOLPACK project. A quick method for 
constructing preprocessors is decr'bed by Boley, 
Grupp, and Theimer. 

Feldman asks, *Why should you do all the 
work?* and suggests mechanizing operations on 
source code, object code, and test data so that 
the programmer is relieved of many of the clerical 
tasks asiociated with programming. Hennell, 
Riddell, and Woodward describe a method for 
measuring the adequacy of test data, fhe method 
is based on testing whether errors deliberately 
introduced into the software (mutants) will be 
detected by the test data. 

Cline's description of a course on 
matbematioal software should be helpful to those 
teaching or planning such a course. Clorl, Mlola, 
and Truffl present an aid for moving large 
programs to a minicomputer. And going in the 
opposite direction, Dodson, Lewis, and Poole 
consider the problem of tailoring mathematical 
software for the CRAX-1. Finally, Hanson and 
Krogh describe a way of passing optional data to a 
subprogram that has little Impact on the user who 
has nc need to pass such data. 

Thanks are due: Webb Miller, Leon Osterwell 
and Brian Smith who helped in the selection of 
invited speakers; to Chuck Lawson who reminded me 
of a few oversights and helped with local 
publicity; to Kris Stewart for (wo)manning my 
phone while 1 was gone for three weeks prior to 
the conference; to Denise Chambers for secretarial 
support; and most of all to JPL for their 
generous support of this conference in terms of my 
time, secretarial support, and the printing of 
proceedings distributed at the conference. 


1 


rORTRAM STAHPARDS, AN OVERVIEW 

Jeanne Adana i NCAR 
Chair, X3J5 

FORTRAN 66 

Fron the early heginninge in the fiftiee, 
FORTRAN was need aa the de facto atandurd 
for Boientifio and engineering eorlc. Aa 
ita uae aproad, the potential for nuiaeroua 
imconpatible FORTRAN dialeota became 
apparent. A rigoroua definition of FOR- 
TRAN in a etandard became neoaaaary if 
continued uee of the language ware to bo 
Buoceaaful. 

In J550, The Amerioan btandarda Aoeocia- 
tion (ASA) eatabliahed the committee for 
Computare and Information ProeeaBing, A 
aubcummittee of thia group wae formed to 
consider common programming languages. In 
May of 1962, a working group beijan to 
study the possibility of introducing a 
atandaj’d for FORTRAN which waa to become 
th* ‘‘iret programming language to be 
atan- rdized in tne United States. 
Manufanturera and user groups sent 
repreeentativea to the Standards Committee 
for FORTRAN (X3-T3). They cooperated in 
the study and preparation of the first 
FORTRAN standard 1X3.9-1966) which was 
released in 1966. Many areas ware con- 
sidered by X3J3 including current usage, 
clarity of syntax, ease of implementation 
and the language's potential for future 
extensions. Two olarifioations were pro- 
duced) one in 1967 and another in 1969. 

FORTRAN 77 

FORTRAN has always been a coat effective 
language) , what it may have lacked in 
elegance and style was gained in effi- 
ciency and ease of implementation. In 
1967, the group responsible for mainte- 
nance of FORTRAN 66 concluded that it 
would require no acre effort to begin on a 
revision then to continue producing offi- 
cial interpretations of the standard. In 
January 1 969, X3J3 voted to begin work on 
a revision to X3-9-1966. The current 
standard X3. 9-1 978 took eleven years to 
complete) seven years were spent in 
preparing the draft, and four years in 
completing the approval process under the 
American National Standards Institute 
(ansi) as it is no« called. One signifi- 
cant result of this eleven year effort was 
that the FORTRAN 77 standard document is 
now more understandable than the 66 docu- 
ment. The standard itself contains six 
times more text in describing FORTRAN 
features than the 'old standard' , result- 
ing in improved readability and clarity. 

An important consideration in the develop- 
ment of FORTRAN 77 was the determination 
not to invalidate programs written in FOR- 
TRAN 66, but to ensure that these programs 
were upwardly compatible, A comparison 
chart of FORTRAN 66 and FORTRAN 77 Will be 
summarized. 


FORTRA N Bx 

There ia always resistance to change In 
programming languages and their asaociated 
standards . A programming language must 
reflect the needs of the user community 
and be responsive to the kinds of applloa- 
tiona that ensure continuing popularity 
among users. At the time of final pro- 
cessing of FORTRAN 77, X3J3 had already 
begun the study of a design that would 
modemiZB FORTRAN, The objective waa to 
keep pace with technology and atate-of- 
the-art programming techniques and allow 
jpplioations specific conventions to coex- 
ist and become part of a family of stan- 
dards for FORTRAN. 

In these early studies during 1970 and 
1979, the committee studied language 
features from many perspectives. The 
emphasis was to examine the language as a 
whole, and how various candidate features 
were related. Surveys of various user 
groups were taken, and these needs were 
placed in a broad enough context so that 
oondidate features for the standard could 
bo chosen within a carefully considered 
framework. In certain areas (i.e. data 
struoturea and program form), development 
Was necessary beo.iuse of a need for a 
function not yet provided in the market- 
place, An architecture is proposed 
(described in more detail in the next 
pi'aasntation on FORTRAN) that Will place 
certain general features in the core, 
while others will be separated into 
modules. Interfacing to special purpose 
applications such as graphics or date base 
schemes is an important part of the techn- 
ical proposal for the next revision. An 
important question concerns the ability to 
identify obsolete features and move these 
out of the language in a graceful way. 

A basic array processing proposal has been 
completed and will be in the new revision. 
In the various surveys on user needs, the 
ability to manipulate arrays as fundamen- 
tal objects Was a very popular request. 

A need has been expressed for a general 
precision data type facility to specify 
minimum precision for floating point 
operations. Numerical analysts have made 
important oo.jtributions to the precision 
proposal!? for the current revision, aa 
well ns to the Environmental Inquiry pro- 
posals which are discussed later in this 
session. 

Liaison Activities 

Liaison has been established with a number 
of national and international organiza- 
tions. One of the very important liaison 
activities continues to be with SIONUM. 
Nationally, X3J3 has established a liaison 
with the Graphics Standards Committee, the 
CODASYL Data Base Group, and the Purdue 
Workshop for Industrial Real Time FORTRAN. 
Internationally, we have a working rela- 
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tienshlp “i^’h th« Bn tlt't Conput«r 
■^ociBty, th« Burop«im Conputar 
Manufaoturar'p Aaiociation, and Standard* 
Qroup* frOB a numSiar of countri** tuch a* 
Auatrla, 0«rB«ny> Swadan and Canada< 

HltiESTOHES 

X3J5 ha* Jaat coaplatad tha first draft of 
a doooB*nt that contain* all of tha propo- 
sals passsd BO far for tha naxt ravislon. 
Tha docuBont is not intsndad to ha t**t 
for tha standard, hut la is organisad into 
saction* such that tha editors can prepare 
text sasily. All new proposals hafora tha 
fiOBMittae ora to ha Bodifie8tti)r.» of thia 
docuaant (Standing DoouBent 6), In this 
way, Baahars Will have a single aouroe of 
Batarial for the next revision. 

Many paopls ask what x is in IQBx. How- 
ever, it ia difficult to answer thia q[ues- 
tion. X3J3 has a milestono chart, but it 
is a working aeheme for astahliahing oom- 
Bittee ohjeotivsB rather then any fixed 
promise for completion. Patea that occur 
before today have been modified to refleot 
actual progress, while datea that follow 
today reflect the committee'e goals, A 
sample mileatone chart haa been prepared 
for thia sassion. 


CORK-AHD-MODULES DESIGN FOR NEXT FORTRAN STANDARD 

Loren P. Meieaner 
Lawrence Berkeley Laboratory 

■The. Proble m 

Fortran isn't going to go away, no matter how much 
ye deplore ita irregularity and inelegance. For- 
tran 77 introduced the hlock-lf and the zero-trip 
DO, and de-standardized Hollerith. But still 
nobody conaidera Fortran 77 a really modern pro- 
graaaing language. 

Can Fortran be modernized; If Fortran were moder- 
nized, would it still be Fortran? Would it have 
any advantage over Faacal? And what would happen 
to the billions of dollars of investment in "old 
Fortran" programs; 

There is pressure from yet another direction to 
influence the future of Fortran. Thia is the need 
for major eztanaiona to the language for the sake 
of a specialized application area (graphics, 
real-time, list processing, array processing, or 
CODASTL dsta base, for example). Incorporating 
any one of these major extensions erodes the prac- 
tical usefulness of the language for anyone out- 
side the apecialized application area. To accom- 
modate them all in a single language would obvi- 
ously be impractical. 


A Proposed Soluttoa 

The ANSI Fortrsn Btandsrds Cotaiibtee, X3J3, it by 
now firmly coamittad to the ides that a "core end 
rtodalcs" approach can solve this problem. Tha 
idea is to defint s "Core Fortran" Isnguase, con-* 
slating of *11 of the "good" features of Fsvtran 
77, plus modern reptaeementa for the "obsolete" 
features of Fortran 77. The obsolete parts of 
Fortran 77 would, however, be retained in an 
"obtolste features Bodula". 

Other "application ares support modules" would 
■atisfy the need for major extenaions needed for 
•pecific application areas. 

Another kini of module, called a "language exten- 
sion module", could add "fancier" features of 
broad application to the language (for example, a 
macro facility). 


sLth& ImuSRt (see Figure 1). By 
the end of the life cycle of the next revision of 
the Fortran standard (in the mid to late 1990'a), 
it 1* assumed that the '‘obsolete" features would 
no longer be besvily used so that the typical 
minumum-confiaui.it ion Fortran compiler would sup- 
port only Core Fortrsn, that is, the "good" 
features inherited from Fortran 77 plus the 
replacements for the "obsolete" parts of Fortran 
77. However, eatlv compilers for the new language 
would necessarily support all of Core Fortran p lus 
the obsolete features module, 

Extended compilers would also support the language 
extension module (or modules). 

It is contemplated that the next Fortran standard 
will include both parts of Core Fortran, the 
obsolete features module, and perhaps one or more 
extenaiou modules. It may be possible to add 
extension modules between revisions of the main 
Fortran standard. Application area support 
modules would be handled as separate "collateral" 
ANSI standards , and in many cases these would be 
developed by a morn or leas independent "task 
group" reporting to the X3J3 committee, rather 
than by the full committee. 


SiiMiizrv 

Hill the result be Fortravi, or will it be a new 
language; It will certainly be a new language-, 
the remarkable thing, if X3J3 is successful, will 
be the creation a new language that :a compatible 
with its predeceasor. 

Hill it be Fortran? Maybe; but only if X3J3 can 
maintain the self-discipline to keep Core Fortran 
a reasonably small language that ia at least aa 
easy to implement and to use as earlier veraiona 
have been. 
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PICURE 1. 

Fortran Core-and-Modul«w SCructura 
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Parallel Processing In Fortran 
Alan Wilson 


Edward J> WUkena 
Perkiii-El„i*r 
Tlntoii FjU#, Hew Jaraey 


INTR ODUCTION 

In peat actiona, E1J1 hna voted to renova cartain 
featurea from CORE FORTRAN, including atoraga aiBoclatlon 
COMMON, EQUIVAEENCE, multiple entry polnta, extended 
DC loopa and atotament functluna. It haa alao voted 
to add, or conaldered for addition, aurh featurea 
an GLOBAE, an'' Internal aubroutinea. 

Thia paper preaenta some propoaed facllltlea to replace 
thoac removed. 

The syntax dearrthad la conalatent with propoaela 
P'ravloualy paeaad and currently propoied In April 1981. 
The area of data aharlng and Internal aubroutinea 
haa been a rather fertile one for propoaala, with 
aeveral varied names and constructs proposed and 
discarded. These do share a significant number of 
common functlom, if not name and syntax, and differ 
primarily because they spring from different sources 
of inspiration. 

DATA ..SH>ftIN(! 

COMMON has been removed from tlie core of FORTRAN BX 
primarily because of the storage association 
properties Implied. However, there Is no intention 
to remove the functionality of a fast, efficient 
global sharing mechanism provided by COMMON. The 
replacement for COMMON, called CEOBAE, eliminates 
storage association. It also provides for a single 
DEFINITION Of the CEOBAE data, with mulriplo uses 
of that deflnltio.i, The following is a typical 
definitions 


ICL, London 


CEOBAE DEFINITION /Shared__data/Real vor,Integer,„vat,Ch.ir'-vur 


The ANSI Fortran committee X3J3 has recently 
accepted proposals for parallel processing In 
Fortran. These proposals have been used to 
express algorithms such as Batcher sort, FFT, 
telephone network simulation, black/white SOR, 
Image processing, noise reduction, least 
squares, solution of linear equations, 
assignment problems, matrix Inversion,... 


As the example Implies, any mixture of types la 
allowed. No specific order of appearance or atorage 
allocation la Implied by the. list of data elements. 
In order for a program unit other than the one 
containing tlte CEOBAE DEFINITION to access the 
CEOBAE data, it must contain a CEOBAE statement 
naming the GLOBAL name (or blank) to bo shared. 

For example; 


An attempt will be made to assess the 
completeness of the proposed language extensions: 

Do they seem to form a basis for the 
expression of (known) parallel algorithms? 

Are they likely to be useful in the search 
for new parallel algorithms? 


GLOBAL /Shnred„data/ 

provides a program unit other Chan the one containing 
the CEOBAE DEFINITION with access to the data oleraents 
In 5h/.red_data by their name. No further definition 
of chose variables is needed. They have all the 
attributes of their declarations in the defining 
program. 
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D«I>«ndfnc CoMpllACion 

All iirugCMi unlCg Hhlifliig a 6I^BAt> t)ata Ana My be 
aeparately conplled. However, the program unit 
containing the CLOBAt DEFINITIOH »u»t be vowpiletJ 
before the othere, Thi» placee a burden on the 
proceeeor to roMunlcate in «om« proceeeor dependent 
fashion the declared varii«'> vi in the GbOBAt, area, 
aa well at their types , diMnelonality.- and locationa 
In the GLOBAb area. It also plarea a burden on 
the progratMwr (or ao»e processor defined user aids) 
to recompile any prograi# unit containing GbOBAt after 
recompilation of a GLOBAL DEPINiriOH In which soma 
infornatlon used by Chose dependent program unlta 
were changed, 

FORTRAii 77 Compatibility 

The primary difference between GLOBAL and COMMON 
la storage association and definltion/use distinction. 
By providing n alwllar but differently named 
funccionalicy, they may be freely mixed in the 
presence of the Obsolete Features Module, GLOBAL 
and COMMON may appear in tlie same program unit, 
provided they refer to different data areaa. 


IMTBRMAL. PROCEDORBS 

Several features removed from CORE FORTRAN In past 
X3I1 actions include control constructs such as 
Statement Functions, ENTRY Statements and Alternate 
Returns. The facilities provided by those constructs 
remain to be pr.jvlded in safer, iBorc conslatant 
constructs. Internal Procedures are provided for 
this purpose, with primary fimctlonallty including! 

Replacement of the Statement Function 
Replacement of extended range of DO LOOP 
Remote code blocks 
Replacement for ENTRY 

An Internal Procedure Is either an Internal Function 
or an Internal Subroutine, which arc similar to the 
familiar Function and Subroutine that serve as 
program units in a FORTRAN program. 

Internal Procedures are located at the end of a 
host program or procedure, immediately before the 
END Statement or another Internal Procedure, 
Deelaratloni for dummy arguments of an Internal 
Procedure arc contained within it. 

Internal Procedures are Invoked from within the 
liost procedure in an identical manner to external 
procedures. 

Name Scoping 

Goals for Name Scoping rules Include regulcrity, 
convenience of sharing as in Statement Fur .'ions, 
safety from accidental error and replacement of 
error prone ENTRY argument rules. These goals tend 
to bo somewhat at odds, and have resulted in 
several proposals and abandonments. An INHERIT 
Statement with a list of names is provided to 
declare what entitles are to be known in the Internal 
Procedure from its host, All other entitles 
appearing in an Internal Procedure are local to it. 

An INHERIT ALL statement has been proposed, but 
not yet passed. 


The INHERIT statement provldaa a regular, safe 
method for sharing data from the host. It does 
not provldw th* convinlenc* of ahering as in 
Statement Functions. A rsplacemont for a Statement 
Function would require an INTERNAL OTCTION, i:HERlT ALL 
assignment, and END INTERNAL statements. 

Packages and Libraries 

ENTRY atatements have often been used in large 
libraries. Problems occur because of the difficulties 
of en‘orelng inaccasslblllty of dummy arguments 
from inactive EHTOYs. EHTR; INTERNAL Procedures 
have been proposed to declare an Internal Procedure 
callable from outside the Host, this all ws a much 
safer functionality for ENTRY, 

Large libraries are normally not compi: <. aj,..- 
one time, n Procedure may be declare * . "I KACE, 
which means that it is to be considered to be Host to 
Internal Procedures which may be separately compiled, 
Wltich Internal Procedures are to be so considered is 
specified in « CONTAINS Statement, Finally, the 
PACKAGE Procedure may be declared to be pure sharnbie 
date with no executable code by declaring it to be 
a SHELL Procedure, 

Data Sharing Revisited 

A SHELL Procedure way be seen to be equivalent in 
functionality to GLOBAL Data. Note that ENTRY, PACKAGE, 
and SHELL have not yet been approved, wheraas 
C'.LOBAL Data has. Since ENTRY and PACKAGE are 
especially desirable features, especially for 
Mathematleal Llbrarloa, SHELL la an obvioua 
extension Co eliminate some almost redundant 
functionality (GLOBAL), However, GLOBAL's strong 
rosemblance to COMMON wakes it attractive. Final 
resolution of these issues remain to be decided. 


A CONSUMER'S REPORT ON 
FORTRAN PROGRAMMING ENVIRONMENTS 

Webb Miller 

Department of Computer Science 
University of Arizona 
Tucson, Arizona 85721 

In this talk we will summarize the attributes of 
several available Fortran programming environments, 
Including the WATFIV compiler and run-time system, 
the Unix operating system and SOFTOOL 80, The 
strengths and weaknesses of each will be discussed. 
In addltlpii, mention will be made of a few avail- 
able frae-8 tending software tools and of come 
planned developments, 

WATFIV has long been tegarded as an excellent sys- 
tem for debugging Fortran programs. This reputa- 
tion is well deserved ! the error messages c< e 
exceptionally clear and the automatic run-time 
checks are quite useful. The system auppoits a 
profiler and a preprocessor for a "structured" 
Fortran. Moreover, an interactive version of 
WATFIV that Includes a symbolic debugger la 
available. 
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Witle WAtPIV !• nut without nutAble UMlttiXon* «nd 
undt«lr«blo Xeatureu ir, th# way it h«ndl»» Furtran* 
lt« swln doficifiuy 1» it» Hutted ecope and ■«» 
chine dependency. Ttie u«er i» left to the nercy 
of the native editoc. file ayateM. etc., and thete 
are often relatively primitive. 

Unix 1* a highly *ucce*»ful operating ayatea de- 
veloped at Bell Laboratoriea and now In place at 
over 2500 inatallatlona world-wide. It ia par- 
ticularly noteworthy at a program development en- 
vironment for orojeeta involving amall numbera of 
programmera. Some of Ita more appealing nttri- 
butea are a nn-nonsenoe command language, a very 
clean file ayatem with automatic updating of de- 
rived fliea, excellent text-proceaalng cspahll- 
lulea including phototypaettlng of mathematical 
equation!, plus a boat of software fragmenta and 
mechanlama for connecting the fragmenta to form 
organized toula. 


Wtereaa earlier versions of Unix aupported Fortran 
only marginally, recent vcralons fe.g., Berkeley 
System Distribution w.O for tlie PDF VAX-ll/780) 
support it himdsomely. Included nre a Fortran pre- 
proceasor that, in mv mind, stands above its many 
competitors, a symbolic debugger an! a Fortran 
Btructurer. 

Perhaps the main weakness of tlic Unix system as a 
whole, beside ita machine dependency, is that It 
has the. steep learning curve that you would expect 
of an operating system designed for expert pro- 
gioamers. The Fortran component of Unix currently 
suffers from a fair number of glitches because of 
Its newness, a cowpl.lnt that should be resolved 
with time. 

SOFTOOI, 80 is an Integrated collection of software 
tools Chat aim to support a particular methodology 
for Fortran progratmalng. It includes not only the 
expected eompon'’nts for static checking, prepro- 
cessing attucturo code, profiling and test cover- 
age reports, but also cools to enforce certain 
programiiJing standards and documentation formats 
sec by management. 

Further information about MATFIV, Unix and SOFTOOL 
80 can be obtained from the following sources. 

WAT NEWS 

Computer Systems Group 
University of Waterloo 
Waterloo, Ontario N2L 3G1 
Canada 

Western Electric Co. 

Patent Licensing Manager 
P.O. Box 20046 
Greensboro, N.C. 27-120 
(919) 697-6530 

SOFTOOL CORPORATION 
340 South Kellogg Avenue 
Goleta, Ca. 93117 
(805) 964-0560 


t.usietlcil Softwire - Visw from the Trenches 
L. W. Lucas 
Naval Weapons Center 

This pseer relates experiences of the author 
over the past seven years as Numerical 
Mathematics Coordinator at the Naval Weapons 
Center Central Computing Facility, evaluating, 
selecting, maintaining ami marketing numerical 
software, and providing consulting, training, 
and docume .tatlon services. The renter is a 
consumer, not a producer, of numerical 
software. Applications include missile design 
and simulation, radar analysis, signal 
processing, detonation physics, and chemical 
kinetics. 


Tentative Outline: 


Implementing a numerical software library 
awareness - Mathematical Software I & M 


starting point - IMSL, dPL library 
literature survey 


additions - GEAR, 

, OEPAC, EISPACK 

NESC test site - 

LINPACK, MINPACK 

Marketing efforts 

documentation - 

Guide, Examples 

short courses - 

Matrix computation 
Numerical solution of 
ODE'S 

Computing random numbers 
Curve fitting 
Least squares 

academic - 

Numerical Methods 


Suggestions to numerical software developers 
user interface 
nami ng 

documentation 
reverse communication 

tradeoffs 

change vs. stability 
flexibility vs. ease of use 

constraints in engineering situations 

sample data systems 
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PACKAGING STATISTICAL SOFTWARE 
Thomas A, Ryan, Jr. 

Hose statistical computations are done using 
widely available statistical packages. In this 
paper, I will discuss primarily the .SPSS, SAS, 

EM0P, P-STAT and Mlnitab systems, which together 
account for a high percentage of all statistical 
computing. Other packages which have influenced 
Che development of statistical packages Include 
Datatext, Genstat, IDA, IMPRESS, MIDAS, Omnltab, 
OSIRIS, SNAP, Statjob. 

Development of statistical packages began with 
the BMD programs at UCLA, in the late 1950's. 

These programs formed an integrated set of pro- 
cedures, but were not a statistical "package" 
in the current meaning of the word. They also 
hud a very primitive user Interface (e.g,, to 
take the log of a variable, the user punched an 
"03" in card columns 10 and 11), In 1968, work 
began on a new series of BMD programs, called 
the P or parameter aeries, which identified 
input parameters with English keywords. 

The initial design of the widely used SPSS 
system was begun in 1965. The publication and 
wide distribution Of the SPSS manual by a 
commercial publisher in 1970 marks the beginning 
of statistical packages as we know them today. 

This manual put computing power in the hands of 
a very wide audience; the design of the SPSS 
system a.llowed even very computationally un- 
sophisticated researchers to use (and abuse) 
the system. 

Most statistical systems began in universities. 

Some (SPSS, SAS, P-STAT, IDA) eventually went 
commercial. Hardware manufacturers have had 
little impact. 

Packaging 

An important aspect of statistical software 
is a strong emphasis on the packaging. Statis- 
tical packages attempt to provide a total environ- 
ment for data analysis, including data management, 
vector (and sometimes matrix) arithmetic, graphics, 
a collection of statistical procedures, and often 
report writers. 

The mathematical algorithms tend to be relatively 
simple and a small port of the overall system. 
Computing time for typical procedures (such as 

least-squares regression) is often less than 
the computing time for inputting the data. The 
routines for output often occupy much more space 
than the key computation routines. As an example, 
UNPACK routines to do regression by the QR 
decomposition, plus routines to call them, total 
about 100 lines. Minltab's REGRESS command con- 
tains over 1,000 lines, The largest portions are 
for creating useful, readable printed output. 

Portability 

Most statistical packages are portable to some 
degree. (SAS, which runs only on large IBM 
computers, is a notable exception.) Most 


packages are undergoing active davelopment, and 
issue a release with major enhancements (some 
of which permeate the entire system) every year 
or two. Each release must be Implemented on 5, 

10, or more brands of computers. Most go on 
mainframes such as IBM, GDC, UNIVAC, Burroughs, 
Honeywell and DEC, and supermini's such as VAX 
and PRIME. BMDP and Minltab also go on 16>bit 
minis such os PDP-11 and HP-3 '■00, 

The major difficulties encountered in porting 
these systems ares (a) their site, which is 
typically 100,000 lines of Fortran code and 
1,000 subroutines, which pushes limits in linkage 
editors and requires heavy overlaying on some 
computers; and (b) Che critical Importance of 
the speed of input and the size of output routines. 
Neither of these problems are encountered in sub- 
routine libraries. 

The roost primitive method of maintaining a (more 
or less) portable package is to develop the 
package on one computer and rely on conversion 
centers to adapt the program to other computers. 
Feedback from converters is used to improve 
portability. This method is still used by SPSS, 

A simple yet powerful way to handle portability 
problems was developed by Roald Buhler for Che 
P-STAT system in 1971. Under his approach, a 
master source is maintained with all versions 
present, A simple selection preprocessor chooses 
the appropriate version based on Cudes in the 
first few spaces of the lines, This approach 
has also been successfully adopted by Mlnitab and 
a slightly modified version has been adopted by 
BMDP and IMSL. 


Interaction with Computer Science 
The developers of statistical packages are 
generally not computer scientists, but have 
learned ,„Gct of the computer science they know 
"on Che Job", iiie principal developers of some 
packages (e.g., BMDP, SAS, Minicab) are statis- 
ticians, for others (e.g., SPSS) the developers 
are consuraero Of statistics (social scientists 
for SPSS) . Some of the developers are involved 
in statistical consulting (e.g., BMDP, Minicab), 
and al.i packages get extensive feedback from 
users. This has tended to encourage sensible, 
realistic refinements and extensions to the 
packages — but probably has focused effort near 
Che existing capabilities of the package rather 
than on developments in totally different 
directions. 

Computer scientists have obviously Influenced 
the designs of the packages and the algorithms 
Included in them. Equally obvious to ut.<>r 5 is 
that Che Influence has not been as great as it 
should have been. For example, there are still 
numerically unstable algorithms in packages, and 
even more inefficient, brute force methods used 
to prevent instability. One reason for the lack 
of Influence has been that statistical package 
developers have often been forced to face problems 
(e.g., in portability and user interface) before 
computer scientists were prepared to give answers. 
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St«il»cicii iuu'k«ft‘> dsvttli'pwra bIhhiW owte wuii 
woFtt vm»i of wlmt ewcputor Molimtlitts know nkout 
(laVBlupnttml of MUnk.U BoEtwoiOi ftlHHit imur 
ioCarfiH-tt, mIjoo.'c tU scrota iilporJthnm, aiul so on. 

Till* luwokM vfouUl b?* >uvlod If tiioro vomput Br 
iiclaivilBt:* otviiUoil MOiiw of tUo lutarootliiR in*ob» 
lows t«cod bv imekopo dovoloporo. Tbo iiiont 
Iwiiorlmit focoM to»* oxcbunRo of Idoiitt 1» the 
ttai’ioM of Mootings, Cowiiutai* Sclenco «ml SUlinUcns 
Anminl 55yni|ioHliiw on tbe Intorliico. 


AUiorUhm Onnkt 

Inrormnti'Jn fiysloio for Mnlbcitinllenl Pnnwnro 

Knnnmt* Aumoo, Mnaokj t'hibn, Akeno MocIiIiIb * 
mill Tiikui'IU Mnodn 

• ['oispul imj I'cnlor 

Ooptirlfflpnl of Intjlnopi'lnt) Hclciiet' 
llokkttujo Unlvornlty, Soppimi llfitl, dppnn 

1 , lot ftKiiiot I nn 

X liiry'r" mSber of nltioriUinm linvo boon proponed 
for aclonlirip cowpulBllonn imd homo of tbom bnvp 
boon jmprovod Bobooooonily. lbo»o ore publlehod 
In nrnny publlcillnna, «nd it 1« not omiy '’or 
Qonornl visorn to find nultitblo nIqoi'''.ni»m for 
tliolr purpotto. Wo Intend to eenatroet on 

inrornmllnn oyiitem for imilhemot lenl nnftwnre of 
fine qunliiy, lUop pointed out Hie 4 teont)tb« 
mid wenknoBoon of twi oppronetien foe uiior 
Intorfoce wllli nlciooltlimai one In tlio pniornm 
llbrm'ieo nmt the ollieo In the oKtondod «yntemo 
iivnilntile ml on Intpqenl piirt of the peooriimmimi 
liinguiHioa. We preoont tiere n htinle Idoii of mi 
nppt'Otieh of the formoe type bmiod on on 
Infovnmt Ion relrlevnl method eomhlned with nome 
ortlfielnl Intelllyenee tophnloopo- A preUmlnnoy 
Implementiitlon Ir oloo roportod. It will mippoot 
Uio followlnt) ntepo In doniqnlnq mid prooromminq 
of problem ttolvinq by compulerst 
. netting up tlie problem in tin npprnpvlole form 
. doHlgnlng the wlqorltlim 
. prognimmiog 

, debugging mid eweeution of the progrom 
. nnniyuiti of the remiltn 
Tlie relrlevnl nyntem uhoulri deol with the 
following two klndn of informnljont 
. Informntlon ooneornlnq indlvidiml nlgorlthm 
, informntlon eoneerning n net of nlgorilhmti for 
n sipoeiflc purpose , Thin kind of infornuiUon 
;»iH ho uneful for aelecUng a miitnhle one, 
nod la enlled nlgoriUimie knowledge in tlita 
paper. 

2, InftirmaUon Repreaentat i on of AlcioriHinm 
TiiqorlTfm^ may ex inf Iri' '.'nrioua formo. i.e,, load 
modolea, amuTP prngramo in widenprend or rattier 
tinrommori programming Inngungen, natural languane 
denerlpHon wltti mathemotlral notation, etr, tine 
may need varloua kinda of information for 
identifying algoiithmn, e.g,, hlhlioiimphle itema, 


apeeiflent ion of funetlons. uaag* of progrnma, 
ete, line of the two alt> inat ivd?, muat he ehoaen 
In deamhe the runetlnni the I irat , proeedurnl 
deneriplion by lugher level Inngungea or 
ooneeplual deaeription by leehnleal termai the 
aeeond. deaeription with aeveral formal a eneh for 
a apeeifie protilem field or denerlpt ton witti a 
Binqle formal for all problem fields. We adopt 
the e>-ieoptual deaeription with n aingle formal. 


Ilip informnUoo repreaentat uin of individual 
nlqorilbm eonajata of Uie fv^llowlng three lypea of 
at tribute. vnUie nett 

U1 bibUogrnplile attributeai I.e., ttie Journal, 
volume, number, page, year, Htle, aulhara, 
elnuBiflenllon eodea, keywords and keyplirBona, 
ole, 

(21 funetlonal altrlbulea, i.e,, the problem 
domain, method, perffirinanee, ete, the 
performnnee us evaUmted by flHI-time. mimher of 
operoliona, memory required, neeurHey, 
robuatneBB, pie. 

m operolionBl nttrlbulea, l.e., the proqrnniminq 
Innquiiqe, imnqe of proqrnma, tealed or not 
tented, ete. 

Ilip vnluea for ttiean ntlribiilea are mostly the 
teelinleol lerma In niBtliemal lea and computer 
aeieneea. riyntaelle rolea ore needed for 
deaeription aueh nn trenlment of apeelnl aymbola, 
Inga, deaerlptora, alnndard forma, ete. 

llila Information repreaentollon aelieme eon he 
regorded na n kind of indeiiing melbod for 

Blqorutima. Problom-orJenled relrlevol bocomea 
poaolbie lo uome extent even with uaiinl 
information retrieval metlioda. Hut a 

mlxed-lnitliitive ditilogue ayulem will be more 
uaeful for eommnn uaera. Then Hie ayiitem ntiould 
deol wlHi the following lypea of Information na 
Hie nlgnrlHimie knowledge: 

(11 knowledge on terms, i.e,. Hie relation of 
aynonyin, auperelnaa and mibelnaa of terma, 
ete, ,'lbort eommenln ore alan uaeful to oanlot 
Hie uaero. 

(21 tiigher level knowledge 
, mnHiemntleal knowledge, for example matrix 
inversion can be regarded na equivalent to 
Bolvlng aiimiltnneoua linear erjollona, ete. 

, empirical knowledge, for eximple matrix 
Invernlon may bt> avoided whenever poaaihle, etc. 
H la pnaalhle to eaoial uaero hy prompting at Hie 
neleelive polnta with the algorllbmie knowledge, 
liiia ran he Implementetl by Hie uoual Information 
retrieval meti id eomhlned with aome artificial 
InteVUtiPnee lecimiguea, any Hie produellon 
oyntem, etc, We can define the tilglier level 
knowledge no a mapping betwinn repreaenlalive 
lerma of funetlonal altribuien. Rlee (21 

dlaeiiaaed the nlgorltlim aeleelion problem and 
propoaori n mnthemotlenl model with Hie problem 
apncB (in some eoaeo feature apa e and rrlterla 
apace are nlao eonaidered), nlgorlthm opnee and 
la'vfQrmnnee menaure npte-e. Tlieae apacea may 

correopnnri to Hie above funetlonal nllrtbulea. 
Our Information relrlevi] metlind in leas 

mnHiemntleal and more empirieal. 
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^ tlibliocirnphlp P niHbPiin 

TTa the rinji step oT TIip tlpvplopfflpnt of our 
8y8lei«, wr hnvr cnnatrurlrd n blblioc>rn,‘''Jp 
(.itnbnar of TAIGO U'ollrrlrd ALGOrJtbms lro« flrm) 
vAurli Inrhirirn rrrt irirntiona find rrmfirka for aomr 
nlqorlthma. In CAinn, Ibrrt' nrr tbrrp prrJnda 
phfirfirtBrlird by Hip atnrt of rollrrllon, tbp 
plnlm for qunllly of piiph nltjDrlHii!i and nfforlo 
Tor iiercaalblJIly lo Ihp rallppHop. Somp of ttm 
propoard nlqorlthma nrr Improved yubaoiiupnlly by 
TOnarko. Itip publlcntlon of CALCO In thp 
Itmqp-lenr form la an npproorh to Hu> 

nrcpaalbtl )ty problrm. An informaHon rplrlrval 
nppronrb by pomputer will hr more pfriplrnt to 
thlB problrm. In our ayati'iii, the rprtlfiPBUono 
and rrmarka nrr mprord into I hr orlqlmil tilqorUhm 
to o.ipply tlip nuqmrntpd informotion. Thla 

dritobnap la now avnllnble nl Ihr Uokkoido 
Univoralty Computlnq Crnter with the rptrirvnl 
Byatcm ORION (Clniinp Rptrlpvpr of InformntlON 
whirb la nvollfiblr on n MITAO pomputer) . Fit).! 
Bhowa nn pxnmplP of Hip retrlevnl prorpsa. 


Msiwupua pg ppitpi* gggiwiuiaiV 
ENTER YOUR REQUEST 
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» la 1 / sMSFa 
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Fiq.l An pxtiinplp of rrlrlrviil of thr rintnbnap 
rALGI) 


Romp sourpp prnqrnmn, thouqb not teated yrti nrr 
aton'd on diako timl rnn hi’ unrd onlinr. Wr intend 
to ponalrupt (i mixpd-iiillintivp dirlonup nyiitem 
for oonip appPifiP ploblrm flplda mi Hip oppond 
stop of Hip drvplopmpnt . 

fonrliidinp Rrmorka 

Wo toivp prcarnlrTro liDBlp Iriri of the Inforrantlnn 
ayntPiii for rnnHienmtiriil aoftwrrp. A Inrqr numbor 
of qunUty olqorltbnm nre now nviillnblp but nro 
(loi ullllzod for ninny usprn. The informntion 

retriPYOl appranoh will be pfrpptivp for 

diaormlnol ion problem of qunlity nmiliemotlpnl 
aoftwnre. 
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(1) a.R.Ripp! Thp Olatrihutlon and nnupppo of 
NatliPmatipiil Software, In MiiHipmatlrnl Software, 
edited by 3. R. Hire, Aendamle Press, 1Q71, 

(2) 3,R,RlpP! The Alqorithm Spieetlon Problem, in 
Advnnppa in Computera, vol.iS, edited by 
M.Rublnofr ot nl., AendemlP Preaa, 197(5, 


SOroiARE MANAGEMENT 
P. M, CafEnoy 

Compucar Sciances Diviaion at* 

Oak Ridge National Laboratory 
Oak Ridge, Tenneagea 37830 

Tlia purpoae of tUla talk 1« to deacriba two software 
aids, oallaii NASTi and NIT,* that have boon developed 
at Oak Riog( for maitkiing numetlqal software. As 
part of our comprelienstvw numerical software ser- 
vice, we linvo acquired a large collection of quality 
routines from sources other than mecbematlcal 
libraries. In order to avoid duplicating the 
acquisition of A piece of software and at the same 
time provide nwers with Information about existing 
software, we liave developed an interactive data 
base called NASTI. Tbia data base Is managed by 
the System 1022 Data Base Management System* end 
Is ovnlliiblu on our I'Dl’-lO computur. The Infor- 
mation contained in NASTI lias been dalibecataly 
kept to n minimum. Time, for eacli piece of soft- 
ware described in NASTI. a computer user has access 
to the following quantities! 

NAME - Name of tlie piece Of software 
PROBLEM - The problem area that the software 
, is suitable for, e.g., Partial 
Differencial Equations 

PURPOSE - A brief description ot what tlio soft- 
wsri* purports to do snd some advice 
on die recomnended use 
METHOD - Thu main numerical metliods used 
ORIGIN - The source of the sofewara 
VERSION - A data which usually signifies whait 
Clio software was acquired 
LOCATION - The location of Che F0RTR/\N Source 
of dm software on our system 

these quantities may be regarded as keys wlilch the 
user may employ during n psrclculat search sequence. 
A disadvantage of NASTI is that the language ot the 
1022 system la clumsy for the casual user. A 
further disudvmitaga is disc since the 1022 system 
is not widely available, NASTI is tion-portnble. 
ilowevfcr, NASTI is an example of an aid wiiich was 
comicrucced using existing facilities, and which 
adequately assTscs in the manngomenC snd Lsssemi- 
naclon of informacion about nuraarical software. 


In ordot to provide users with advice on the correct 
choice of a numerical routine for a particular 
problem, wo have developed a numerical interactive 
tree called NIT. During a NIT session, n computer 
user is nsked certain questions in an attempt to 
identify the particular routrno or group of rou- 
tines which are base suited for solving die user's 
problem. By responding to cheaa questions, the 
user is led effortlessly to a tocomraendacion. At 
prsaene, NIT forms the basis of a system which is 
being developed for on-line documencaclon. Thus, 

NIT has die capability of providing HELP files and 
also gives sufficient luCormation to enable a user 
CO incorporate dm recommended sofewara in a FORTRAN 
program. Moreover. NIT also gives Informacion on 
how CO execute this program on the various computers 
available at Oak Ridge. Unlike NASTI, NIT is port- 
able, because it has bean wtitceu to conform to 
die PFORT^ verifier. Thus, NIT may bo Inseallod 
on a variety of coraputoca. 
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Th* Calk will contain a briaf dttcvlptlon of NASTI 
and an axplanatlon of the dcvalopmant of HIT co- 
gathar with propoaad axcanalona. 


k'. W. Gaffney, J< H, Wooten, and K. A. Keasal, 
"NIT - A Nuaarlcal Interactive Tree," ORNL/CSD/ 
TM-139. 

^"Syateai 1022 Data Baaa Managaaenc Syacea,'' Soft- 
waca Houaa, Caabrldge, MA Q2138, 

^"Tha PFORT Variflar," Software Practice and 
Exparianca., 4 (1974), pp. 359-377. 

^Operated by Union Carbide Corporation under con- 
tract H-740S-eng-26 with the U.S, Departoent of 
Energy. 


The Programming Environment's 
Contribution to Program Robustness 

H. Kahan 

University of California 
Berkeley 

A robust program to solve a quadratic ax2 - 
2bx ♦ c “ 0 will conceal from its user any 
over/underflow in the discriminant b‘ - ac 
while revealing over/underflow just when a 
calculated root lies out of range. In general, 
robust programs conceal spurious exceptions from 
their users while rendering faithfully those 
exceptions pertinent to final results, If this 
assertion characteri jes program robustness 
truly, than robustness is iifipractical in most 
programming environments and a challenging task 
even in so favourable an environment as is 
specified by tie proposed IEEE standard for 
floating point arithmetic. 


A Hardware Unit for Decimal Arithmetic 
with Controlled Precision 

T.E. Hull, Department of Computer Science 
University of Toronto 

Introduction 

The main purpose of this paper is to describe briefly 
the capabilities of an arithmetic unit called CADAC 
(for Clean Arithmetic with Decimal Base and Control- 
led Precision) which is currently being constructed 
[1] at the University of Toronto. 

The unit is Intended to support language facilities 
(including exception handling, and programmer con- 
trol of the precision and exponent range of the 
operands, as well as of the operations performed on 
the operands) such as have been advocated by the 
author [see, e.g,, 2J. Previous attempts to imple- 
ment these ideas have been based on preprocessors, 
which suffer from shortcomings in terms of both 
flexibility and efficiency. The building of CADAC 
is intended to provide hard data on what trade-offs 
are involved if the basic ideas are supported by 
the hardware. 


It is Intended that CADAC be Interfaced initially 
with a PDP-11/34, whose 16-blt wordlength has 
therefore influenced the design. 

The language facilities 

As explained in wore detail elsewhere (see [2] and 
the references given there), the proposed language 
facilities allow the progranaer to specify separate- 
)v the precisions of the operands (along with the 
exponent ranges), and the precision (and exponent 
range) of the operations to be performed on the 
operands. There ace two main ways in which Che 
programmer can take advantage of this capability: 

(1) one is to be able to carry out intermediate 
stages of a calculation with a precision ani/oc 
exponent range that is higher chan the opernndsi 

(2) the other is to be able to repeat a portion of 
a calculation wltli higher and higher precision and/ 
or exponent range until some criterion (such as an 
error requirement) is satisfied. The second capa- 
bility is the more complicated; the program outline 
given below (which illustrates the main features 

of an algorithm for solving equations to within a 
prescribed tolerance "col") Illustrates what we 
have in mind. 

float(8) root — precision 8, default exp. 

— other declarations, etc. 

p ■ 8 “ initialize precision 

flag » true 

while (flag - true & p S 32) 
begin preclsion(p) 

float (p) approximation 

find approximate solution 
find error bound 
if bound s tol 

root •• approximation 
flag - false 
end if 
end begin 
p - p+4 
end while 

Number representation, aritlmotlc. exceptions 

The first 16-bit word of a raemor ,- location is 
interpreted by CADAC as shown In the diagram shown 
below: 


Sign S- 

1 

1 

10 (exponent E) 

4- 

—length 1 








The number of decimal digits in the normalized 
significand 1s 2L+2, and they are to be found in 
succeeding words, 4 per word. E is the cxccss-512 
exponent. E “ 0 is reserved for the value 0, un- 
less S is negative, in which case the first 4 bits 
of the next word are hexadecimal F, E, etc., to re- 
present "indeterminate", "not-yet-assigned", etc. 

If X “ 1 the format becomes "extended" and both 
exponent and length, as well as the digits, are to 
be found in subsequent words. 

Properly rounded floating-point arithmetic is 
carried out. It turned out to be relatively effi- 
cient to work only with multiples of 2 decimal 
digits. Other rounding modes are also provided, in 
particular so that Interval arithmetic can be 
supported easily. 
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CADAC has 0 alngle accumulator, communlcaCea with 
ItB heat In DMA mode, and maintains an exception 
Btatus register for the host. A 3-stage pipeline 
cunning at 10 Mlis handles 2-digit by 2-dlgit pairs, 
and liiultlplics two 32-digit numbers in about 30 
mlccosecondt • 

Exceptions (including overflow, underflow, and 
roundoff) are flagged. Wraparound results ace left 
after overflows ond underflows, indeterminate after 
zero-divide, 


Cost 

Two large boards are used, each with close to 100 
integrated circuits, including a mixture of SSi up 
to LSI, costing a total of about $4000 (Can,) for 
the two hoards. Another few liundccd dollars are 
needed for tlie interface board, power supply, 
cabinet and cables. It is expected that the total 
time required for the design, and for construction 
of the prototype, will be about 2 man-years (Can.). 
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[1] M. Cohen, V.C. Hamachcr and T.E. Hull. 

CADACi An Acltlimetlc Unit for Clean Decimal 
Arithmetic and Controlled Precision. IEEE 
Fifth Symposium on Computer Arithmetic, Ann 
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[2] T.E. Hull, Desirable Flosting-Polnt Arithmetic 
and Elementary Functions for Numerical Computa- 
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A Brief Guide to the Literature on Supercomputara 

Myron Ginsberg 
Computer Soionca Department 
General Motors Research Laboratories 
Warren, Michigan 48090 

As 2-D and 3-D roatheraatioal models oomo closer 
to raf lectins real-world behavior, there is a 
substantial increase in the number of 
floating-point operations which must be 
performed as the grid structure is refined j for 
example, doubling the number of grid points in a 
2-D problem produces a 4-fold increase in 
computing and for a 3-D problem in time there is 
a l6~fold increase. Machines in the emerging 
class of supercomputers offer some alternatives 
for parallel computation in attempting to deal 
effectively with such problems. 


The bibliography given below provides a sampling 
of references to the literature associated with 
parallel algorithms (Geotion I), vector 
architecture (Section II), performance testing 


(Section VI), and apeoifio auiieroomputera such 
as Cray Research's CRAV-l, (Seotlon III), 

Control Data's Cyber 200 Series (Section IV), 
and the recently cancelled Burroughs Soientifle 
Prooessor (Section V). The author welcomes 
readers to submit additional recent referanoea 
in any of the aforementioned areas. 

The oral presentation will focus attention an 
point-by-polnt ooraparisons of the CRAY-1 and 
Cyber 203. Efflpha,sis will be placed on those 
attributes which directly affect the design and 
implementation of mathematical software for such 
superoomputers. Also, results will be presented 
from a variety of performance studies involving 
the CRAY-1, IBM 3033 i and several other computer 
systems. 

I. Parallel Algorithms 

1. Brent, R. P., "The Parallel 
Evaluation of General Arithmetic 
Expressions," J. ASsoo. Comput. 

Mach. . Vol. 21, No. 2, 1974, pp. 
201-206, 

2. Chen, S. C., D. J. Kuok, and A. H. 
Sameh, "Practical Parallel Band 
Triangular System Solvers," ACM 
Trans. Math. Seftware , Vol. 4, No. 3, 
September 1978, pp. 270-277. 

3. Oajski, D. D., "Solving Banded 
Triangular Systems on Pipelined 
Machines," Proceedings 1979 
International Conference on Parallel 
Processing . August 1979, pp. 308-319. 

4. Heller, D., "A Survey of Parallel 
Algorithms in Numerical Linear 
Algebra," SIAM Review . Vol. 20, No. 

4, October 1978, pp, 740-777. 

5. Rung, H. T., "The structure of 
Parallel Algorithms," Advances in 
Computers , edited by M. C. Yovits, 
Vol. 19, Academic Press, New York, 
1980, p. 65-112. 

6. Miranker, W. L. "Parallel Methods for 
Solving Equations," Parallel 
Computers - Parallel Mathematics - 
Proceedings of the IMACS(AICA)-G1 
Symposium , a lited by H. Feilmeier, 
North-Holland Publishing Company, 
Amsterdam, 1977, pp. 9-15. 

7. Miranker, W. "A Survey of Parallelism 
in Numerical Analysis," SIAM Review , 
Vol. 13, 1971, pp. 524-547. 

8. Ortega, J, M. and R. G. Voigt, 
Solution of Partial Differential 
Equations on Vector Computers . Report 
No, 77-7, ICASB, NASA Langley 
Research Center, Hampton, Virginia, 
March 30, 1977 J also in Proceedings 
of the 1 9 77 Army Numerical Analysis 
and Comnutera Conference , U.S. Army 
Research Office, Research Triangle 
Park, North Carolina, March 1977, pp. 
475-525. 
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9. Poole, W, 0. and R. 0. VolRfc, 

"Nuinerioal Algoritbnis for f'arallol 
and Vector Computers! An Annotated 
Bibliography," ACM Comput. Rev. , Vol. 
15, No. 10, October 197*1, pp. 379-388. 


10. Saroeh, A. 11., "Numerical Parallel 
Algorithms - A Survey," High Speed 
Computer and Algorithm Organization , 
edited by D. J, Kuok, D. H. Lawrie, 
and A. H. Sameh, Aoadomlo Press, New 
York 1977, pp. 207-328. 

11. Sameh, A. H. and D. J. Kuok, 
"Parallel Direct hinear System 
Solvers - A Survey," Parallel 
Computers - Parallel Mathematics - 
Prooeedings of the IHACS (AICA)-Ql, 
Symposium , edited by M. peilraeier. 
North - Holland Publishing Company, 
Amsterdam, 1977, PP 25-30. 

12. Stone, H, S., "Parallel Tridiagonal 
Equation Solvers," ACM Trans . Math . 
Software . Vol. 1, No. *!, December 
1975, PP. 289-307. 


II. Computer Arohiteoture Considerations 

1. Chen, T. 0., "Overlap and Pipeline 
Prooessing," Introduotion to Computer 
Arohiteoture , edited by H. S. Stone, 
Solenoe Research Associates, Chicago, 
Illinois, 1975, PP. 375-**31- 

2. Haliin, T. 0. and M. J. Flynn, 
"Pipelining of Arithmetic Functions," 
IEEE Trans. Comput. , Vol. C-21, 1972, 

pp. 880-886, 

3. Kozdrowioki, E. W. and D. J. Theis, 
"Second Generation of Vector Super 
Computers," IEEE Computer , Vol. 13, 
No. 11, Novamher 1980, pp. 71-83. 

4. Kuok, D. J., "A Survey of Parallel 
Machine Organization and 
Programming," ACM Comput. Survey , 

Vol. 9, No. 1, 1977, pp. 29-59. 

5. Kuok, D. J., D. H. Lawrie, and A. H. 
Sameh (eds.), High Speed Computer and 
Algorithm Organization , Academic 
Press, New York, 1977. 


6. Lawrie, D, H., "Access and Alignment 
of Data in an Array Processor," IEEE 
Trans . Comput . , Vol. 0-25, No. 12, 
1975, pp. 1145-1155. 

7, Raroamoorthy, C, V. and H. F. Li, 
"Pipeline Arohiteoture," ACM Comput. 
Survey , Vol. 9, No. 1, 1977, pp. 
61 - 102 . 


8. Rudsinski, L. and J. Worlton, Tne 
Impact of Soalar Performance on 
Vector and Parallel Processors . 

Report LA-UR-76-2656, Los Alamos 
Soientifio Laboratory! Los Alamos, 

New Hexloo, 1976s summary in High 
Speed Computer and Algorithm 
Organization , edited by D. J. Kuok, 

D. H. Lawrie, and A. H. Sameh, 

Academic Press, New York, 1977, pp. 
451-452. 

9, Sugarman, R., "'Superpower* 

Computers," IEEE Spectrum . Vol. 17, 

No. 4, April 1980, PP. 28-34. 

10. Voigt, R. G., The Influence of Veotor 
Computer Arohiteoture on Numerical 
Algorithms . Report No. 77-8, ICASE, 
NASA Langley Research Center, 

Hampton, Virgins, March 31, 1977! 
also in High Speed Computer and 
Algorithm Organization , edited by D. 

J. Kuok, D. H. Lawrie, and A. H. 

Sameh, Academic Press, New York, 

1977, pp. 229-244. 

Til. Cray Research's CRAY-1 

1. Ames, W. G., P. G. Bunlng, D. A. 
Calahan, D. A. Orbits, and E. J. 

Sesek, Sparse Matrix and Other 
High-Performance Algorithms for the 
CRAY-1 , SEL Report No. 124, 

Department of Electrical and Computer 
Engineering, Systems Engineering 
Laboratory, University of Michigan, 

Ann Arbor, Michigan, January 25, 1979. 

2. Asprey, M. W., "Veotorlzation from a 
Large Code Point of View," 

Proceedings of the 1978 LASL Workshop 
on Veotor and Parallel Processors , 
compiled by B, L. Buzbee and J. F. 
Morrison, Conference Proceedings 
LA-749I-C, Los Alamos Scientific 
Laboratory, Los Alamos, New Mexico, 
October 1978, pp. 16-40. 

3. Buzbee, B. L., Implementation of 
Algorithms on the CRAY-1 , report, Los 
Alamos Soientifio Laboratory, Los 
Alamos, New Mexico August 1978. 

4. Buzbee, B. L., G. H. Golub, and J. A, 
Howell, "Veotorlzation for the CRAY-1 
of Some Methods for Solving Elliptie 
Difference Equations," High Speed 
Computer and Algorithm Organization , 
edited by D. J. Kuok, D. H. Lawrie, 

A. H. Sameh, Academic Press, New 
York, 1977, pp. 255-271. 

5. Calahan, D. A., "A Block-Oriented 
Sparse Equation Solver for the 
CRAY-1," Pro p. 1979 International 
Conference Parallel Prooessing , 
August 1979, pp. 116-123. 
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IV. Control Data's Cy'oer 800 Series 


6. Calahai , D. A., W. 0. Ames, and E. J. 
Seeek, A CoUeotlon of 
Eouatlon-Solvlng Codea for the 
CRAY-1 . SEL Report No. 133, 

Department of Eleotrloal and Computer 
Engineering, Systems Engineering 
Laboratory, University of Michigan, 
Ann Arbor, Michigan, August 1, 1979. 

7. Cray Research, CRAY-1 Fortran (CFT) 
Reference Manual , Publication No. 
8290009 (Revision 0) Cray Research, 
Inc., Mendota Heights, Minnesota, May 
1980. 

8. Gray Research, CRAY-1 Hariware 
Reference Manual , Publication No. 
8840009 (Revision E) Cray Research, 
Inc., Mendota Heights, Minnesota, May 
1980. 


9. Cray Research, The CRAY-IS Series of 
Computers , Publication No. 229000BD, 
Cray Research, Inc., Mendota Heights, 
Minnesota, I960. 

10. Cray Researoh, Scientific 
APDlioations Package Handbook . 
(Revision B), Cray Researoh, Inc,, 
Mendota Heights, Minnesota, January 
1981. 

11. Higbie, L., "Applications of Vector 
Processing," Computer Design , Vol. 

17, No. 9, April 1978, pp. 139-195. 

18. Higbie, L., Veotorization and 
Conversion of Fortran Programs for 
the CRAY-1 (CFT) Co m piler . 

Publication No. 289C207, Cray 
Researoh, Inc., Mendota Heights, 
•Minnesota, June 1979. 

13. Johnson, P. M., "An Introduction to 
Vector Processing," Computer Design , 
Vol. 17, No. 2, February 1978, pp. 

89-97. 

19. Orbits, D. A. and D. A. Calahan, Data 
Flow Considerations in Implementing a 
Full Matrix Solver with Baoklns Store 
on the CRAY-1 . Report No. 98, Systems 
Engineering Laboratory, University of 
Michigan, Ann Arbor, Michigan, 1976. 

15. Petersen, W. P., "CRAY-1 Basic Linear 
Algebra Subprograms for CFT Usage," 
Technical Mote No. 2290808 Cray 
Research, Inc. Minneapolis, 

Minnesota, February 1979. 

16. Russell, R. M., "The CRAY-1 Computer 
System," Communications of the ACM . 
Vol. 21, No. 1, January 1978, pp. 

63-72. 

17. Sites, R. L., "An Analysis of the 
CRAY-1 Computer," ACM SIOARCH 
Newsletter, Vol. 6, No. 7, April 

1978, pp. 101-106. 


1, Control Data Corporation, CM Cyber 
LOO Fortran Language 1.5 Reference 
Manual for" Use with CPC Cyber 200 
Operating System 1.5 , Revision B, 
Publications and Graphics Division, 
Control Data Corporation, Sunnyvale, 
California, August 1980. 

2, Control Data Corporation, CPC Cyber 
200/Model 2 05 Computer System, 
Publioaion tio. 60256020 (Revision 1), 
Control Data Corporation, St. Paul, 
Minnesota, September 29, 1980, 

3, Control Data corporation, CPC Cyber 
200/Model 205 Technical Description , 
Control Data Corporatioi), 

Minneapolis, Minnesota, November 1980. 

9. Hoffman, D. E,, A Parameter Study of 
a Vectorized Chebyshev Algorithm on 
the CPC Cyber 203 . Control Data 
Corporation, Pelham, New York, April 
1980. 

5. Kasoio, M. J., Jr., "A Direct 
Poisson Solver on STAR," Proceedings 
of the 1978 LASL Workshop on Vector 
and Parallel Processors , compiled by 
B. L. Buzbee and J. F. Morrison,- 
Conference Proceedings La-7991-C, Los 
Alamos Scientific Laboratory, Los 
Alamos, New Mexico, October 1978, pp. 
137-165. 

6. Kasoio, M. J,, Jr., Vector Processing 
on the Cyber 200 , Control Data 
Corporation, St. Pau3 Minnesota, 

1979! also published in Infoteoh 
State of the Art Report 
"Supercomputers", November 1979 and 
in Angewandte Informati k, January 

1980, pp. 27-37. 

7. Kasoio, M. J., Jr., Vector 
Prooesssing; Problem or 
Opportunity? , Control Data 
Corporation, St. Paul, Minnesota, 

1979! also published in IEEE COMPCON 
'80 . November 1979 . 


8, Lambiotte, J. J., Jr., Effect of 
Virtual Memory on Efficient Solution 
of Two Model Problems , Technical 
Memorandum TM X-3512, NASA Langley 
Researoh Center, Hampton, Virginia, 

1977. 

9. Lambiotte, J. J., Jr. and R. 0, 

Voigt, "The Solution of Tridiagonal 
Linear Systems on the CDC STAR-100 
Computer," ACM Trans. Math. Software . 
Vol. 1, No. 9, December 1975, pp. 
308-329 . 

10. Lincoln, N. R., "It's Really Not as 
Much Fun Building a Supercomputer as 
It Is Simply Inventing One," High 
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Spaeci Cowputer and AlROPitlm 
Oi»aani;ention , adited by D. J> Kuck, 

D< H. baurliii and A. H> Saraaiii 
Aordomio Prasa, Naw Yonk, , pp. 
?-U. 

U. UnOo3> , N. R., A Sat'anl through tha 
Control Data STAH-XOO ultli Oun and 
Camera . paper, Control Data 
Corporation, Arden Hilla, NlnneaotR, 
W8. 

12. Moaabers, B., An informal Approach to 
NuBber Crunohlng on the Cyber 
2Q3/S0R . Control Data Corporation, 
Cyber 200 Support, RSHOilN, 1801 West 
County Pond B, Roseville, Minnesota 
58113, March 1981. 

13, Noor, A. K. and R. E. Fulton, "Impact 
of CDC STAR-100 Computer on Finite 
Elements Systems," J. Struct. Div. , 
ASCE, Vol. 101, 1975, pp. 731-750. 

II). Noor, A. K. and S. J, Hartley, 
"Evaluation of Element Stiffness 
Matrices on CDC STAR-100 Computer," 

J. Comput. Struoturas , Vol. 9, No. 2, 
1978, pp. 151-161. 

15. Noor, A. K. and J. J. Uarabiotte, Jr., 
"Finite Element Dynamic Analysis on 
CDC STAR-100 Cowputer," Computers and 
Struotures , Vol. 10, No. 1, 1979, pp. 
7-19. 


16. Rothmund, H. J. and K, L, Murphy, 
ProKrammiiiK MatliodoKy for CDC Cyber 
205 Vector Processor , Control Data 
Corporation, St. Paul, Minnesota, 
August 1980. 

17. Radhed, D. D., A. W, Chan, and S. C, 
Itotovy, "Now Approach to the 3-D 
Transonic Flow Analysis Using tha 
STAR-100 Computer," AIAA Journal . 

Vol. 17, No. 1, January 1979, pp. 
98-99. 

V. Burroughs Soientifio Processor 

1. Burroughs Corporation, Contro l 
ProKram - Burrouahs Soientifio 
ProoBssor . Burroughs Corporation, 
Paoli, Pennsylvania, November 1977. 

2. Burroughs Corporation, Ovei-view, 
Perspective, Arohiteotura - Burroughs 
Soientifio Processor . Burroughs 
Corporation, Paoli, Pennsylvania, 
February 1978. 

3. Burroughs Corporation, Floating Point 
Arithmetic - Burroughs Scientific 
Processor , Burroughs Corporation, 
Paoli, Pennsylvania, December 1978. 

It, Burroughs Corporation, Implementation 
of Fortran - Burroughs Soientifio 
Processor , Burroughs Corporation , 
Paoli, Pennsylvania, Novorabor 1977. 


5. Jensen, C. "Taking Another Approach 
to Superoomputing," Datamation . Vol. 
24, Ho, 2, February 1978 , pp. 159-172. 

6. stokes, T. A., "Burroughs Soientifio 
Proesaaor," High Speed Computer and 
Algorithm Organisation , edited by D. 

J. Kuok, D. H, Uawrle, and A. H. 

Sameh, Academic Preae, Naw York, 

1977, pp. 85-89, 


VI. Soma Performance Testing and Benchmark 
Results 

1. Boloy, D, 1.., "Veotorisation of Blcok 
Relaxation Techniques - .Some 
Numerical Experiments," Proceedings 
of the 1978 LASU Workshop on Vector 
and Parailei Processors , pompiued by 
B. L. Buabae and J, F, iksrrlson. 
Conference Prooeedlnga LA-7491-C, Los 
Alamos Scientific Laboratory, Los 
Alamos, Naw Mexico, Ootober 1978, pp. 
166-173. 

2. Buoy, R. S. and K, D. Senna, 
"Nonlinear Filtering Algorithms for 
Parallel and Pipeline Machines," 
Parallel Computers - Parallel 
Mathematics - Proceedings of tha 
IMACS (AICA) - 01. Symposium , edited 
by H. Failmeier, North-BollBnd 
PublKhing Company, Arastardara, 1977, 
pp. 9 >97. 

3. Calahan, D. A., W, N. Joy, and D. A. 
Orbits, Preliminary Report on Results 
of Matrix Benchmarks on Vector 
Processors I Report No. 94, Systems 
Engineering Laboratory, Department of 
Electrical and Computer Engineering, 
University of Michigan, Ann Arbor, 
Michigan, May 1976. 

4. Dongarra, J., Soma LINPACK Timings on 
the CRAY-1 . Report No. LA-7389-HS, 

Los Alamos Soientifio Laboratory, Los 
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Tlut Use of Extensible Languages 
for Hathenatical Software 

A Custt Study 

L, M. Delves 

Department of Computational A Statistical Science 
University of Liverpool, Liverpool, England 

1 , W itat and Wliy 

GEM ?'Is’ a general program for the solution of 
elliptic partial differential equations 

-VA(x)Vf(x) + B(x)f(x) t- C4(x).Vf - g(x) (I) 

subject to a variety of boundary conditions, over 
arbitrary bounded or infinite two dimensional 
regions, It was written in the extensible lang- 
uage Algol 68, and this paper outlines the advant- 
agea of this approach. These depend strongly on 
the ability within this language to define not 
only new modes, but operators on these modes; end 
to include absoluuely anything Inside a structure, 
and to deliver abiolutely anything as the result 
of a procedure, 'flie advantages which accrue 
include! 

d) Ease of witing . The program is wiiAten in 
terms of objects: lines, elements, differential 
equations, boundary conditions; which are natural 
to the mathcmaticul problem, 

b) Ease of debuKRing . These same features make it 
easy (well",' easier) to locate and remove bugs. 

c) Provision of g natural user interface la also 
simplified; it is possible to let the user see the 
highest level structures directly, and to provide 
a convenient and natural language in which he can 
describe his problem. We believe that GEM2 is 
easier to use than any other PDE package; this is 
achieved without any pre-processor being required. 

d) Extensibility . Equation (1) may represent a 
single or a set of coupled equations, with real or 
complex (scalar or vector valued) functions 

A, B, C, g, f, 

GEM2 is written in mode-independent form; the 
underlying field is represented via a predefined 
mode seal , the choice of this mode determining 
the class of equations covered: 

Class 

Single real PDE 
Single complex PDE 
Coupled real PDES 
Coupled complex PDES 

Tt:e body of the code Is written in terms of the 
mode seal ; the four versions differ only in the 
provision of a small (( 100 Tines) prelude con- 
taining declarations of the primitive data type 
(e.g. mode seal « ref [ ] real) and of a few 
primitive operators on objects of those modes. 
Tliesc features of GEM 2 offer an interesting 


mode seal ; 
real 



ref t ] compl 
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<lanMn«tratlon of tlia uie of an exianalblu 
language in o non-t)?lvlal mathemat’lcal aofcware 
environment! we eaticate that thejr nave cut the 
development coata by a factor of three to five. 


2 . H0» 

CBM i 'implementa the Global Blewent method tli2]j 
that ia, the given region ia aubdivlded into (a 
few) elementai theae are mapped onto a atandard 
region (& equate) and a high-order orthogonal 
polynomial approximation uaed within each napped 
element. T)ie objecta required to implement Che 
method include aides (of elementa); elements; 

»apBi differential equation coefficients; differ- 
ential equations; boundary conditions. Eacti of 
these has a corresponding mode declaration ixi 
GEM 2. Sample (skeleton) mode declarations irclude; 

mode sidefunc « struct (Union (proc ( real) real, 
prop t J real , real) real) func, ref [ ) teal 
params) ; 

mode sid e » struct [l!3] real position, int 
modon [IS2] sidefunc shape) ; 

mode eleaw nt - struct ( ref t ] int side numbers, 
variety of other stuff); 


tlie effect of these declarations is that elements 
are described in terras of tlieir edges; and thr 
user has a fairly wide choice of modes of descrip- 
tion of a side: Cartesian, polar, or parametric 
coordinates, with or without parameters. As in- 
dicated, the actual structures contain a yarf.aty of 
other useful but more tecbnical bits and pieces; 
we found it extremely useful during development to 
be able to add another field to the defining 
structure and have the appropriate infomation 
propagate painlessly through the entire program. 
Note also (for PASCAL addicts) that we keep 
procedures inside structures; we cannot imagine 
writing GEM 2 without this facility. We also make 
extremely free use of the ability to generate 
global space dynamically (the "heap"). Unions 
("variant records") are used to yield a flexible 
interface for the user. 


HOW SUGCESSPUL (was the decision to use 
Algol 68) f ltie answer to thin haa three aspects i 

_g Did it help implementatiof ? At We are totally 
hooked. “ 

5 How about runtime efficiency? A; Depends on 
your implementation! on our computer, (ICL I906S) 
Algol 68 runii about as fast as FORTRAN. 

£ How easy to ')so is GEM 2 really? A; Try to judge 
from the following complete program. 



User proBram i 

begin problem L shape; describe problem (L shape. 

irtT; 

real ab,be,cd.de,ed! read ((ab,bc,cd,de)) ; 

e’Fi"">“ nb + cd; fa: » be + do; 

print ((newline, "ab bo cd de", ab,bc,cd,de)) *, 

t ] real origin; “ (be - fa, -ab.0,0) 'c' global^ 

local origin at corner c^f 'c'; 

point a ■ (fa, 0,0), b " (fa,ab) , c ■ (fa - bc.ab), 

d - (fa - be, af), e - (0, ef), f - (0,0, 0,0); 

Triangle (1, (5,6,7), '’o,b,a), origin, 1,2/3, 

false ); 

Triangle (2, (7,1,8), c,a,f, origin, 1,2/3, false) ; 
Triangle (3, (8,2,U),c,f,e, origin, 1,2/3, false ); 
Triangle (<l, (9,3,4), c,o,d, origin, 1,2/3, false); 
Internal ((7,8,9)); Neumann ((1,3, 4, 5)); 

Diriclilet (6 , constan t 1 ,0) ; 

Dirichlet (6, constant 0.0); 
for n from 3 to 9 do 
solve (n, 1,0. 1, T; 

Tabulate ( s yoparams currant value, null defunction, 

6 , 6 ) 

si 

end 
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DavttI R. Hanson 

Dep«'*i»wnt of Computer Science, The University of Ariron# 
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I, Introduction 


refers to /tourc«/pf»/ailoc.rat. Files and directories ure equivalent 
with the exception that diredories ennnot be written by the user. 

The primitives that deal exclusively with the directory s ucture are 
summarized in Table I. 


Ta ble I. I’lVi Directory Primitives 


fihdirfnamo) 

llnk(riamo1,nama£) 

mkdlr(oame) 

rmdir(nama) 

ttat(nama,array) 


change current directory to name 
make a link to namel named name2 
make a directory named nama 
remove directory named nama 
return information about file nama 


Input/omput is one of the most machine-dependent aspects of pro- 
gramming, especially for portable software. The large range olito and 
file system capabilities among existing computer systems makes it 
extremely difficult to avoid idiosyncratic problems in even the most 
carefully engineered portable systems. A typical solution to this 
dilemma is to use the 'standard* i/o and file primitives defined in the 
language in which the portable system is written [tan78]. In Fortran, 
for example, it is common practice to use only the forms of the i/o 
statements defined In the ANSI standard, and to use verifiers that aid 
In the detection of non-standard constructs [ryd74]. Another common 
approach is to define a small set of relatively low-level i/o routines that 
Can be easily implemented and can model the capabilities of most com- 
monly available file sysiems. By funnelling all I/O through these rftu- 
tines, portability problems arc isolated in their machine-dependent 
implementation. The software described in [ker76] is evidence of the 
success of this approach. 

A problem with these traditional approaches is they invariably Sacrifice 
capability and efficiency for portability. Designs based on these 
approaches tend to have only the 'lowest common denominator* in 
capabilities of the intended host systems, such as sequential If o to char- 
acter files of restricted names. Enhancements may of course be added, 
but at the expense of an Increase in implementation complexity "ind a 
reduction in portability. 

The heart of the problem with traditional approaches to portable i/o 
systems lies in their attempt to manipulate highly machine-dependent 
objects—host machine files and file names. This paper describes a 
portable file system that makes files and their names machine- 
independent. The molt importan' advantage of this approach Is that 
i/o is not limited by the target systems. For example, capabilities such 
as random access, multiple access, and automatic expansion of files, 
which are absent in some commercial operating systems, are provided 
by the portable file system. 

The portable file system— PFS for short— is the combination of a port- 
able file directory system [han80a, hanSI] and a portable i/o system 
[hanSOb]. It provides machine-independent files and file names, a 

hierarchical directory structure in which to organize files, and a set of 
directory manipulation and i/o primitives. The directory structure and 
primitives arc similar to the structure and primitives of the UNIX [ritV41 
file system, The PFS is, in large part, a portable implementation of the 
UNIX file system. It is packaged as a set of Ratfor tkcr75] (and hence 
Fortran) functions and subroutines, which is loaded with thv program 
or system that uses it. The implementation techniques are similar to 
those used in UNIX [tho78] and arc described in [hanSOa) and [han8Cb]. 


2. Dkreclorfes 

The directory structure in the PFS is a rooted tree structure in which the 
leaves are files or directories and the nodes arc directories. A dircciavy 
is simply a list of files and directories. The root c ‘the tree is denoted 
by /, and files and directories are denoted by their 'path*, which speci- 
fies their absolute position in the tree, 

A path is composed of the names of the nodes on the path from the 
root to the desired file or directory. The path components arc 
separated by slashes, e.g /source/pfa/alloc.ral. The names and *,.' 
refer, rencctively, to the directory itself, and to Its immediate ancestor. 
These n. ncs may be used as path components, providing a explicit 
means of using the structural properties of the tree. If a file name does 
not begin with it is taken to be rooted at the 'current directory*. For 
example, if the current directory is at /aource/pfa, the name alloc.rat 


The current directory is changed by chdlr. link cstabiishes alternate 
names for a file. Directories arc created by mkdlrand, once empty, are 
deleted by rmdir. Information about a file 'or directory), such as its 
size and date of creation, is returned by atat. 


3, Primilives 

A nti/ilt is similar to a file in Unix and may be thought of as a finite 
sequence of characters or bytes. The pFS is insensitive to the range of 
byte values, so it can accommodate both 'binary* and 'character* files. 
Primitives are provided to create, delete, and open files, and to read 
and write characters anywhere within a file. Files are as large as is 
necessary to accommodate what is written to them, but are otherwise 
featureless. The basic primitives arc summarized in Table |l. Most 
primitives return a value indicating the success or failure of the 0 |>crn- 
tion. 


Table II. PFS I/O Primitives 


(d « lop*n(namo,mode) 

(d lcreate(name,mod3) 
fcloaeffd) 

n s freadfbuffer, count, fd) 
n K (wrlts(buffer,couni,fd) 
pos = (pos(offset,type,ld) 
(remove (name) 


open file name 
creute u,-id open file name 
close a file 
read from a file 
write to a file 
position *i/o pointer* 
delete file name 


Existing files are opened for i/o by (open. The argument name is the 
name of the file and mode is READ. WRITE, READWRITE, or 
APPEND and indicates *how* the file is to be acassed. If the file exists, 
(open returns a 'file descriptor’, which may be thought of as a 'handle* 
that is used to access an opened file. Descriptors are similar in concept 
to channel numbers or Fortran unit numbers. Their values are never 
inspected cxpliciilv but arc passed to other primitives to indicate the 
opened file On Which they should operate. 

New files arc created by foreato, which creates the named file and 
opens it us if (open had been called. If the file already exists, it is trun- 
cated to zel 0 length and opened, 

Opened files arc closed by (close(fd). 

Data transfer to and from opened files is performed by (read and 
(write, (read reads -ip to count characters from tiic opened file indi- 
cated by the file descriptor (d into butter. It returns the number of 
characters actually read, which may be 0 when the end of the file is 
reached, (write writes count characters from buffer to the file indi- 
cated by Id. Writing beyond the current size of the file is permitted, 
and ih: file is automatically cxte.ided to accommodate what is written 
to it. For symmetry with (read, (write returns the number of charac- 
ters actually written. 

An ‘i/o pointer* is associated with each opened file and is advanced by 
(read and (write, it can be repositioned by (poa according to the 
values of offset and type, If type is 0, offset specifics a position rela- 
tive to the beginning of the file; if type is 1 , offset specifics a position 
relative to the end of the file; and if type is 2, offset specifics a position 
relative to the current positon of the file, fpos returns the previous 
position of the file. 

Files arc deleted by (remove. Deletion of opened files and files with 
aliases is permitted; the file is actually deleted upon the removal of the 
last reference to it. After deletion, all space occupied for the file is 
available for reuse. 
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4, CuHchitium 

Hie iioti«ble flit syiiem piavulci « macliine-imlepcnJeiU wncept nf 
file flitj 1 o primilivcs slwt offer *rcaier flembilitj? than i« foumJ m 
many operating lyslema It ii iypieally more cnteient than llie traiti* 
tional approaches to portable t o systems l-or examplei measure* 
mcMis on a OrC'IO and Cyber 175 show a 25-15 percent improvemcm 
over l-ortran i o for sequential character files 
I’cthaps the best eharactcriraiiait of Pis ii an abstract data type ‘file*. 
It pros ides a data striicture, file, and a set of operations on that 
struciwre This characteti/aiion clarifies the important difference 
between the pis approach and traditional approaches, which attempt 
to provide a set of operations on imspecdied and highly machine* 
dependent data tirucitires host maehme files 
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TOOLPACK- A Collottlon of 
Tools for Mstboranticnl Software* 


Uon Osterwall 
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Inttoduetlon 

TOOLPACK is a cooperative project Involving 
reseatchera at Argonno National Laboratories , Bell 
Teleplione Laboratories , Intornatlonnl Hathematical 
and Statistical Libraries, Ire., Jet Propulsion 
Labaratory, Numerical Algorithms Croup, Ltd., Pur- 
due University, Unlveralty of California nt Santa 
Barbara and University of Colorado. Ttio project 
is being funded by the Dept, of Energy and the 
National Science Foui'datlon, aa well as the parti- 
cipating institutions* TOOLPACK has aa its objec- 
tive the conveyance of strong comprehensive tool 
support to programmers who are writing, testing, 
transporting or analytlng mntboiuatlcal software. 
Hence it must provide strong support for documen- 
tation, testing, and verification, as Well as such 
code creation activities as editing* 


A Wide variety of tools will be built and adapted 
to eupport these ectivltiee> It ie expected Umt 
these tools will be .distributed as stand-alonB 
entitiee* Utere is, however, contidereble support 
and sentiment in favor of cresting an Integrated 
collection . of .the tools .ts . will. Tlyis.papar 
presents s brief overview of the dei * - 

plans for this integrated collection. . — 
ing summary is extracted from lOate 811, wherein 
additional details can be found. 

Before commenelna with description of the. de.slgn, 
it is important to enunciete the following basic 
assumptiona; 


Seslgn of. and 
The follow- 


ahall be carefully chosen to span the needs of as 
broad and numeroua a uiar community aa ia practi- 
cal. 


2. TOOLPACK is to be designed to provide cost 
effective support for the production by up to 3 
programrera of programs, whosa length la up to .5000 
Tinas of aource text. TOOLPACK may be lesa effec- 
tive in supportiiig larger projecta. 

3. TOOLPACK is to be designed to '..rovide coat 
effective support for the enalytis and transport- 
ing of programs whose length la up to 10, OOP lines 
of source text. TOOLPACK may be lets effective in 
supporting larger projects. 


4. TOOLPACK Will support users working in either 
batch or interactive mode, but may offer stronger 
more flexible support to interactive uaera. 


A. Overview 

A primary motivatirs goal of the TOOLPACK 
integrated tool Collection design, is that user 
support be supplied in as direct, and painless a 
fashion as 1-. feasible. In parc.lcular, the design 
attempts vo relieve thu user of having, to, under- 
Btand flu' natures and Idlosyncraalea of Individual 
TOOLPACK tools. It also relieves tlie user cf tlie 
burden of having to combine or coordinate these 
tools. Instead the deaign encourage! the user to 
express his needs in terms of the..requlrements of 
his own software job. The TOOLPACK support ayscem 
is designed to then ascertain, which tools are 
necessary, properly configure, those tool.s. and 
present the results of using the tools to the user 
in a convenient form. 

The design encourages the user to think of TOOL- 
PACK aa an energetic, reasonably bright assistant, 
capable of answering questions, performing menial 
but onerous tasks and storing and retrieving 
Important bodies of data. The aim of this is to 
make humans more effective in creating, document- 
ing, testing and verifying program code, 

In order to reach this view, the user .should think 
of TOOLPACK as a vehicle for eitabUshing and 
maintaining a file system containing all infowa- 
tlon important to the user, and using that file 
system to both furnish input to needed tools and 
capture the output of those tools. Clearly, such 
a file system is potentially quite larga and la to 
contain a diversity of atored entitlea. Source 
code modules would certainly reside in the file 
system, but so would such more sresne entities. as 
token lists, and flowgraph annotations. In order 
to keep TOOLPACK*! user image as straightforward 
as poEBlble the deaign propoaea Chat moat file 
system nanaseraenc be done automaClcaliy and inter- 
nally to the TOOLPACK system,. out of the sight and 
sphere of responaiblllty of the user. The user 
may create, delete, alter and rename these, enti- 
tles. The user may, however, also manipulate 
cliese entitles with a set of commands which selec- 
tively and automatically configure and actuate the 
TOOLPACK tool ensemble. The commands ace designed 
CO be easy to understand and use. They borrow 
heavily on the terminology used .by programmers in 
creating and testing code, and conceal the aome- 
tlmea considerable cool mechanisms needed to 
effect the results desired by the user. 
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I. I'ttr Vliibln Kilt SyatM Cnclcitt 


In nrJ»r to •nrouratt and {aellltatt tht practdiini 
vI*M of TOOtiFACKi tha ayataa will luppoct the nur- 
Ing, atnraia, ratrlavalt aditlng and aanlpulatlon 
ot cite following el«ii««a of anutloti wlUeh ihould 
lie eontideted tn be tl« baal- onjtctc of WUPACKi 


1* Pr3gr«» smitsi 


A iiHiM'ACK j'rogM« unit (PI) 1» the aa*a ua « Por- 
tfiii progMti unit I axt epc that th*J!.P.w;k will 
riHulve fi nunlwr of repraientationa of the pfograa 
unit other than th* anurea rod# (a.g., the 
enrrtaponuing tukan liat and paraa traa> • 


i KxerutloB I’nlci! 


Any aet of TOOLPACK progran unite which the uaar 
cluioaea to dtalgnata, can ba grouped into a lOUi.- 
I’Affi execution unit (EC). 

1. Teat Data CoUactiona: 


A Ti OUAt'K teat date collavtlon (TDC) it a oollac- 
tlon »f teat data tata to ba utad in axareiaing 
one or more TOOLPACK axacutlon unita. 


4. Options Packett! 

A TiHibPACK ootlona packet (OP) i« a lat of direc- 
tive a apecitylng which of the Many anticipated 
optlona are tn he in force for a particular invo- 
cation of » particiilar TOtU.PACK cool. 


C. The TOOLPACK Gonmand Language 

The cxiU't ayntax for the TOOLPAGlt integrated tool 
collection coraaand language has not been 

CBtabllahed and la atill under study, currently 
wo are In a poaition, however, to apecify «uch of 
Che ienantlc content of chl» language. 


The proposed TOOLPACK comnand aet reams to divide 
logically into four parts! file system management 
commands, edit (synthesis) commands, tool applica- 
tion (analysis) commands, and perusal commanda. 


1. File System Manipulation 


Theac will facilitate 
renaming and general 
filea. 


the creation, deletion, 
maintenance of TOOLPACK 


2. Edit (aynthesis) 

Tliese commands would .summon special purpose edi- 
tors designed to facilitate the manipulation, 
examination and alteration of the contents of the 
various TOOLPACK file system entities. 

3. Tool Invocation (Analysis) 

Hiese commands invoke the functions which are at 
the heart of the raaaon for the TOOLPACK project - 
namely the facilitation of documentation, testing, 
veriflcaClon, transportation, and source program 
entry. Consequently, great pains are being taken 
to make them easy to understand and use. In an 
important sense, the rest of the TOOLPACK command 
language has been designed so as to make these 
tool in> ocntlo,.a straightforward. 

FORMAT 


Invocation of this command causes a named program 
unit to be taken as input to the TOOLPACK format- 
ting tool. 

b. STRUCTURE 


Invocation of this command causes a named program 
unit to be taken as input to the TOOLPACK struc- 
turer , 


c. ANALYZE 

Invocation of this command results in the static 
analysis of the entity named. If the entity is a 
pcoRraa unit, then alngle unit analysia will be 
performed. If the entity is an execution unit, 
then each program unit will be analyzed 


individually and integration analysis will also ba 
performed. 


An options peeks t may ba specified by the user. 
This, packet will enable the. user to apectfy a 
lavel of .thoroughness which will cause analysts to 
go as far as the lexical level the syntactic 
level, the static semantic level or the data flow 
level. »f this apeciticatlon is omitted, the 
TOOLPACK System will select a default option 
(probably full data flow analysis). 

The reiuXts of this analysis will be placed into 
an sntlty-attrlbute-relaMonal data base idilqh 
will then be available for perusal by a browsing 
subsystem or for use as the basis for report gen- 
eration tools wiiose goal would be the creation of 
superior docuaentatlon. 


d. EXfXUTE TEhT 


invocation of thla command results in the dynamic 
test execution of a coUeetlen of test data sets 
by a specified execution unit. Die test data sets 
comprising the test data collection are fed into 
the execution module derived from the execution 
unit one at a time, with the results of each exe- 
cution being used to build an execution history 
data basu. This data base would be used to supply 
answers to user-poaed questions as well as reports 
needed for documentation purposes. 


Ttie user may optionally specify a teat optlona 
packet whose purpose is to select and specify 
which of the numerous execution monitoring optlona 
are to be employed during the test runs. The 
power and flexibility of the dynamic test monitor- 
ing system is to be considerable (see (Feib SI]). 
Thla Is deemed to be necessary, but la also con- 
sidered to be a serious problem, In that a casual 
or novice user may be intimidated by the variety 
of available choices. Hence it Is proposed. that a 
set of standard Test Optlor , Packets (TOP a) be 
prepared by the builders of tha dynamic test moni- 
toring system and stored permanently in the TOOL- 
PACK file avstom. Users could select from amone 
these, tailor' them to Individual needs by. uslf,- 
the TOP editor, or create their own TOP s frou; 
scratch. One of the standard TOP* a would be con- 
figured to be the default TOP, enabling the uaer 
to do useful dynamic teating without needing to 
specify any TOP. 


i; 


4 Perusal 

TOOLPACK will ultimately contain tools to facili- 
tate the examination of the various entities in 
the TOOLPACK file system. This abstract has 
already mentioned various. special purpose editors, 
part or whose purpose will be to facilitate exami- 
nation of the user-named file gyatem entities 
(e.g., the Py source. text, EU*a, 0P*a and TDC’s). 
A different sort of tool Is desirable for use in 
eruslng the output of the static analysis and 
ynamic testing cools. As already noted, these 
tools will produce as output sets of analytic and 
diagnostic packets which are most profitably 
viewed as relational data bases. Tools tor effec- 
tively browsing these data bases could be specifi- 
cally constructed to efficiently scan these date 
bases for answers to expected queries. Existing 
text editors will probably serve as primitive 
forarunnerg of these tools in early releases of 
TOf'JLrMCK. 

!). Itipleraentotlon Plana and Schedule 

The TOOLPACK integrated tool collection is 
Bcheduled for public release in January, 1983. 
Preliminary releasas to test sites will take place 
during 1982. Individual toola will be made avail- 
able intermittently. 
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SOFTOOL 80 
A METHODOLOCTf AND 
INIEGRATED COLLECTION OP TOOLS 
FOR. SOFTMARR MANAGEMENT. DEVELOPMENT, 

AND MAINTENANCE 

by 

EDWARD MEllLSCHAU 
SOFTOOL CORPORATION 
3W SOUTH KELLOGG AVE, 

GOLETA, CALIF, 931X7 

SOFTOOL 80“ is a methodology and an integrated 
collection of tools that addreaBaa the entire 
aofeware development proccaa. Releaae I of 
SOFTOOL 80* addreaaea the programming phaae of 
Boftware development ^thau ic, the portion of the 
software development life cycle that beglna after 
a detailed deaign document has be.tn generated and 
concinuBB to the point where a complete, deliver- 
able software product has been prodviced). 
Forthcoming releases of SOFTOOL 80" addrese the 
remaining portions of the aoftware life cycle. 
This paper outlines a subset of SOFTOOL 80“ 
Release 1 that provides a powerful environment 
for the development of mathematical software, 

SELECTED TOOLS 

The AUDITOR! 

The AUDITOR Is a software product that automati- 
cally documents Fortran programs for deviations 
from a user-defined standard, poor programming 
practices, and non-portable coda. 

The American National Standards Institute (ANSI) 
definition of Fortran is used by the AUDITOR as a 
baseline or default standard. A user can defln 
any standard desired by instructing the AUDITOR 
to allow extensions to the ANSI definition. The 
AUDITOR incorporates a powerful compile-time 
diagnostic capability equal or superior to that 
of the best commercial compilers. The roossoges 
generated can be classified into six categories: 

1. Error Messages — definite violations of 
the standard. 

2. Warning Mesaages — potential violations 
of the standard. 

3. Portability Messages — program 
transferability problems. 


Ibe IHSTRWffiNTERSs 

Under 8'FTOOL 80", Fortran programs ara instru- 
mented for three different porposei! tracing, 
teatlng, and optlmiratlon. The TRACING IMBTRimPTERS 
generate profiles that indicate the levult (i,e., 
routine, statement) and the path traversed by the 
program flow of control during execution. The 
TESTING IMSTRUMPTERS generate profiles that 
indicate the coverage and effoctivenM'! of test 
runs. The 0PTIH12AT10H INSTRUMPTFDS osnerate 
profiles that pinpoint the most tiiu -onsumlng 
««otiona of rode in a system. 

The INTERFACE DOCUHENTER! 

Tlie purpose of the INTERFACE DOCIMENTER is to 
generate clear, up-tvdate, and complete docu- 
mentation of ail interfaces between object modules. 
Reports produced include! 

1. A complete cross reference of all symbols 
defined or referenced in the object 
modules which were input to the tool. 

2. A list of all symbols referenced but 
not included in the modules input to 
the tool for analysis, 

3. A list of all aymboli not referenced by 
any of the modules procassad by the tool. 

A. A summary of the interconnections and the 
lengths of all the object modules proeeaaed 
by the tool, 

5, A Buamary of all recursion chat occured in 
fee modules input to the tool, 

6. Two optional reports known as explosion 
and imploalon. Explosion displays the 
hierarchical structure of all aymbola 
referenced, directly or indirectly, by a 
user specified symbol. In other words, 
explosion displays the subsystem referenced 
by the specified symbol, Implosion, on the 
other hand, shows the hierarchical atructure 
of all aymbola that refersnea the given 
symbol. 


The PRODUCTIVITY LIBRARY! 

The PRODUCTIVITY LIBRARY allows the user to 
Interactively define high level data structures 
and provides a set of primitives for manipulating 
and searching the defined data structures from 
the user program. Range checking and dynamic 
flow analysis can alao be specified for the user- 
defined data structures. With range checking the 
user may specify values that data structure items 
ate allowed to assume. Dynamic flow analysis 
allows the user to specify allowable flow transi- 
tions for a given item in a data structure. 
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SUMMARY 

Tha obj active of this paper la to outline a «ub»et 
of tha toola available under LOFTOOh 80" 

Relanaa I. Theae toola act aa a fine alevei 
formlns an environment for the davalopaont of 
mathematical aoftware that ellmlnatea a large 
claaa of potential problems. These problems 
would otherwise manifest themselves at a later 
time aa "bugs". 

Tha tools available uuder SOFTOOL 80" Release I 
that ware not described In this paper include! 

. ahort-hand language 

• structured langurje 

. source codiL documentera 

• dynamic memory managers 
. tutorials 


A Support Environment for Software Tools 
Fred T. Krogh and W. Van Snyder 
Oet Propulsion Laboratory 


1. Introduction. 


We sumnarize here a support environment useful 
for the development of software tools, described 
more fully in [1]. There are five components: 
I/O Primitives, filing system, working storage 
manager, symbol table manager and lexer / par- 
ser, The working storage manager, filing system 
and I/O primitives collaborate to provide a seg- 
mented virtually addressable storage access 
method similar to the Multics environment: a 

user program can 

"directly address just those items it 
needs from the extensive on-line data 
files, so that eich reference to such 
items can (in the logical sense) be a 
single operation. The actual reference 
need not be preceded by an input/output 
system request to input a (partial copy of 
the) file, nor be followed by an input / 
output system request to output the alter- 
ed information to its original location." 

[ 2 ] 

2. I/O Primitives . 

The primary function of the I/O primitives is to 
provide a transportable and efficient interface 
to the idiosyncrasies of various operating sys- 
tems. Software tools require services provided 
by sequential character input and output devices 
such as keyboards and printers, and sequential 
and direct access storage devices. 


To provide efficiency, access to sequential 
storage devices is asynchronous and double buf- 
fered; the details of the provision of such ef- 
ficiency are hidden inside the primitives charg- 
ed with providing such functions. Operating 
system services providing synchronous and asyn- 
chronous access to direct access storage devi- 
ces, and services required for synchronization 
of the primitives with operation of the devices 
are used to provide efficient direct access. 


3. Filing Sy stem. 

The filing system is responsible for storing and 
organizing representations of program units, and 
tables required by higher level tools. The fil- 
ing system allows the user to express relations 
between objects. The user, for example, is al- 
lowed ( encouraged 1) to declare that a program 
consists of a related collection of subprograms, 
etc. The operating environment of the filing 
System is provided by the I/O primitives and the 
working storage manager, 

A .simple model of the filing system is a road 
map (of one way roads). An object is accessed 
by specifying an ordered list of "roads" to be 
traversed to proceed from a standard starting 
place to the desired object. A collection of 
objects is denoted by a path to some part of the 
road map from which the collection, but only the 
collection, may be reached. The road map is 
represented as a directed graph. Roads are rep- 
resented by edges in the graph. Intersections 
of roads, and objects in the filing system, are 
represented by vertices in the graph, 

4. Working Storaqe Manager . 

The working storage manager operates in the en- 
vironment provided by the I/O primitives and the 
filing system, and in turn provides Important 
features of the environment needed by those 
tools. The primary function of the working 
storage manager is to provide space to other 
tools, and recover that space when it is no 
longer needed. Any significant restriction of 
the amount of space available to a high level 
tool is not acceptable. The working storage 
manager is therefore also responsible for 
providing the illusion of unlimited storage 
capacity. 

Providing the illusion of unlimited storage cap- 
acity is usually accomplished by the use of a 
heirarchical storage system, where frequently 
used data are retained in main storage, and in- 
frequently used data are retained on secondary 
storage. There is a correspondence between ad- 
dressing spaces managed by the working storage 
manager, and objects in the filing system. The 
filing system is used for the secondary storage 
medium required to provide the illusion of un- 
limited storage capacity. In return, informa- 
tion in the filing system is accessed as though 
it were stored in the main memory, rather than 
by the direct use of I/O primitives. This mech- 
anism imposes very little overhead. 
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5. Swnbol TahiP Manager, 

The symbol table Is logically divided Into three 
parts: a local symbol table for each program 
unit, describing local characteristics ot var- 
iables, constants, labels, control structures 
and other objects; a global symbol table for 
ea,'h program unit and collection of program 
units describing Interface Information for each 
program unit and the relations between calling 
and called subprograms: and a language symbol 
table describing such objects as keywords, In- 
trinsic funetions, and spelled operators. 

Access to objects In the symbol tables Is provi- 
ded by funetions, which shculd he expanded In 
line rather than called, These functions assume 
the object to be accessed Is In male memory - an 
illusion provided by the working storage manager. 

The lexer and parser are usually assunwd to be 
separate tools. But a Fortran lexer may bo made 
significantly simpler if the parser Is available 
to give It advice. The Integration of the lexer 
and parser does not impose an unbearable storage 
penalty on applications needing only lexical 
analysis. 

The lexer / parser is controlled by tables, 
stored In the standard filing system, and acces- 
sed by the working storage manager. This allows 
one lexer / parser to accept several dialects of 
Fortran, preprocessor dialects, or commands, de- 
pending on the tables used to control Its opera- 
tion. 

All Input to and output from the lexer / parser 
1s accomplished by the working storage manager. 
If the source text is not an object in the fil- 
ing system, the working storage manager provides 
the Illusion that It Is. At the conclusion of 
analysis, the source text may be retained In the 
filing system If desired, even If 1t was not 
originally an object In the filing system. A11 
other products of the analysis may also be stor- 
ed In the filing system as desired. 


y. Reference s. 

1, Fred T, Krogh, W. Van Snyder, Section 366 
Computing Memorandum A76, Oet Propulsion 
Laboratory (May 1981). 

2. Elliott 1. Organick, "The Multics System: 
An Examination of its Structure," MIT 
Press, Cambridge, MA (1972) p 1. 

This work represents the results of one phase of 
research carried out at the Jet Propulsion 
Laboratory, California Institute of Technology, 
under contract No. NAS 7-100, sponsored by the 
National Aeronautics and Space Administration. 


A iMclIiotl for (‘oiistructiiiii l*rc(iroccssors 

Daniel 1 . Doley, William 1). Oiopp, ami 
Marvin M.llicimer 


Many pruprainming and command lanpiiapcs provide 
only limited reaiuies and painrul user-imeilliccs (e.p,. 
liuuan and Jt*l ). 1’u'piiKe.s.sors me piogiams that ean 
extend and lerormal such Imiym.ipes using tumslalion 
techniques akin to compilers, t iiey can he valmihle tools 
in die development of maihenutkal .solTwaie. However, 
wiiiing a pieprocessor ean be a time consuming task. 

We pit'sent a method for quickly eonsiuicting a 
preprocessor from a foimal dcseiiption of the language to 
he transimed. We llrst dl'ciiss the properties to expect 
fioin a good prepii'cessoi. We then dcsciibe how we 
used ixisimg techniques to achieve these goals. We 
present an e\mu|ile of n liilUKAN piepioeo.ssur 
construeied by oui system. 

A giHHl preprocessvii should have the following pioiieities. 

■ It must he e.isy to write the prepiocessoi correctly, 
and it sliould petfurm reasonablv eiTicicntly. 

• I'lror lecovciy mid lepotiing should be p.iu of the 
foi'iiuilisni wheie possible, not just m udiiendimi. 

• It slunild I’C e.isy to modifv the l.uigiiage accepted by 
the iwepiocessor. 

- lliere must be the capability to escape back to the 
base language. 

■ The ptepioeessor will luivc to be iioilable. 

• The generated output code should be reasonably 
elTlcienl .mil readalde. 

To adiieve the.se goals, we make the following 
iveomendations. l-ii-st. a pseiido-t\impiler aiiproacTi 
should he taken. This jirovides a modular framework 
employing a .scanner module lo reeogni/e iiiinit tokens or 
symbols, a parser module to reeogni/e the sviilax of the 
language, a semantic ixiekage to generate tlie desired 
output, mid an error package to handle error recovery. 

.Second, the input language should be fonnally speeilied 
using u syntax grammar with atlaelied sonumtie actions. 
This provides a concise, easily modifiable description of 
the Innguage whielt fils nicely into the pseudo-compiler 
ii|iproncb. 

Tldrd, the above iTioices along witli the typo of ea|)" 
abilities usually desired imply tliat the most dilTicult parts 
of the preprocessor can be written using well-established 
tools and leehniques. 

Finally, use the simplest approach possible. Unless 
nvailabie as a package, a more powerful teclinique may 
yield very little ndvnntage. 

As an example of an netiml implementation of these ideas 
we present die choices made for our implementation of mi 
extended Rnifor preprocessor for Fortran, 



Scf, unci': 

Our scnnner is "Imml-built". We considered using n 
scanner eencruior package to automaiically generate a 
scanner routine; however, a suitable package was not 
easily available. Since most (>rcprocc.ssor .scannere are 
very simple, it is often true that a -d-built veision is 
sulllcicnt and can be constructed quickly. 

Parser; 

A table-driven parser was built. This kind or paiser is 
small, fast, and allows easy modification ol' the input 
grammar. Of die two main techniques in use (U, and 
LR) we chose the less powerftil LI, one. The reasons Ibr 
this were tlrnt an LI, parser is easier to create and makes 
certain types of error recovery easier. The ftict ttmt this 
technique cannot handle ns large a class of languages as 
LR was of no real arncern since it can handle the type of 
input languages that most preprocessors arc oriented 
towards. 

.Semantic package: 

This section of the preprocessor was again harid-inilored 
to the application. This is primarily because we know of 
no practical technique which allows a formaliration of this 
area. However, by using a sclteme of grammar attached 
semantic actions, it is possible to divide up the tasks of the 
semantic package into small, manageable pieces. 

Rrror package; 

Hy using an I I, paraing technique it is possible to 
automatically detect, report, ami recover llxnn syntactic 
errors in an input program. Unfortunately, semantic 
errors in a program must still be handled in ait ad-lioc 
fashion (litis is also true for a,tt LR parser). 

In suittntary, our basic attitude was to follow a pseudo- 
atittpilcr nitproaclt usiitg whatever tools or tcchitiques 
were available or easy to iittplcittcnt, 

Currently we have an extended version of the origiital 
Ratfor prcpixx'c.ssor of Kernigitan aitd Plauger 
Intplcmeitted using our approach. The final version will 
include the following extensions: 

- data sinictures, foremost of which are records aitd 
variable-origin arrays. 

- an onipiit code format Utat is as readable ns possible. 

- various special operators, including itrray-bnscd 
operators. 

• cxceiilioit time profiler to allow easy invocation of 
tintiitg statements. 

• frec-formnt I/O. 

Some other preproccssora dtnt could be coitstructed with 
tiiis method arc: 

- a prepioccssor for the IBM VM operatiitg .system 
Miitmaitd language. 

- a PDR language on top of Fortran. For example, this 
language could be oriented towards convenient 
specification of mesh refinement programs. 

- an array language, perhaps oriented toward 
optimising code produced for a specific vector machine, 
(Prcpixxessod constructs allow for painless insertion of 
nsseinbly-levcl language.) 

- a front-end interface for large madicmntical softwa'rc 
packages. 


h Nutation Analyaia o( Nuiaeclcal Software 

M.A.llonnoll, I.J.Hlddoll and M.K. Woodward 
Dept. Coiaputational » Statistical Science 
university of Liverpool 
Liverpool L69 3HXf U.K. 


One convincing w.ny to demonsteato that a 
particular program contains no errors Is 
to generate systematically all the poasibilltiea 
and then demonstrate that the test data 
can detect them alll A more realistic 
approach in advocated by Do Millo HI who 
ban constructed an interpretive syotom to 
generate many simple errors, e»g. errors 
in Individual lexemes, in such a way that 
each error la oCCeotively inserted in its 
own copy of the original program. Theoe 
copies with needed errors are known as 
"mutant programs". The idea is then to 
construct tost data which kills all the 
mutant programs by showing incorrect output 
xlata. Mutants which are equivalent to the 
original programs will, of course, remain 
live. 

Tliere are a number of problems with this 
approach, one of which is the enormous 
number of mutants which might bo generated. 
For instance, for a thirty line program, 
fifteen hundred mutants is a coaltstio 
possibility and the number of mutants 
grows roughly with the square of the length 
of the program. Therefore, a specialised 
system (such as that of 11)) is required 
for practical use. 

tiowevec, there are various subsets oi 
mutants, not necessarily exclusive, wi’ ;ch 
may bo of particular intorost and for 
theoe subsets the number of genet atod 
mutants may be manageable in a conventional 
compile and run system. The authors have 
built a mutation system whicl) utilises a 
standard editor together with compilers 
and run-time systems for FORTRAN, COBOL 
and ALGOL68. 

In this paper we describe our experiences 
using the fortran version of the mutation 
system to analyse the adequacy of the teat 
data sets for a number of numerical routines. 

Wo have analysed three subsets of mutants. 
Ttie first subset is that arising from the 
relational operators. Prom a statistical 
analysis 12) of numerical software we know 
that, on avecago, there will be eight 
relational operators pot routine, and, 
since each relational opocstor can bo 
replaced by five alternative relational 
operators, we obtain a total of about 
forty mutants per routine. The subset is 
therefore manageable and in also of intoraat, 
since testing the predicates is one of 
the more difficult aspects of path testing, 
particularly If the predicates are complex. 
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The teat dat» a^^aquacy o£ 14) la definoiJ 
as 

M “ nuinbgf pC Jead mutanta 
total numDoeot mutants 

We have meaaucofl the teat data adequacy £oc 
a nurobec of NAc; coutlnea and the ovecage 
value of M Eou these coutlnes i» 0.6G 
(with a atandaed deviation of 0.22). 
Unfortunately it la extcemoly difficult to 
dlBtlnguiBh the equivalent pcogcama from 
the comalnlng live mutanta, ao the adequacy 
of the teat data may bo aubatantlally 
higher than thia measure indicatoa, Out 
reaulta ahow that conventional test data, 
which does not achieve particularly good 
coverage in terms of ,say, the TER motriea 
of Old novetthelosa does tend to detect 
simple errors in the relational operators. 

The second subset is the control flow 
mutants. Mutants are created which affect 
the Clow of control, such antltievt atet 

a) negating the relational operators 
and logical values 

b) replacing labels in each computed 
GOTO and arithmetic IP by 
permutations of the othor labels 

c) inctsmonting the upper index of DO 
loops . 

Tost data to detect those errors will in 
general need to achieve coverage ratios 
close to TER2 * 1.0, although TBUl « 1.0 
does not need to be satisfied. This is due 
to the logical IPs, since, for example, 
only one log of an IP-THEN-EISE construct 
would need to be executed to detect a 
negated predicate. The results for this 
subset yield an average ratio of 0.57 
(standard deviation 0.27) C^--. the routines 
tested, h mote detailed inspection of the 
roselts, however, reveals that this ratio 
is boosted by a high percentage of dead 
mutants in category a) (averaging 80%) 
compared to the relatively low percentage® 
of dead mutants in categories b) and c) 
(aver.aging about 40% in each case). Slenco, 
these results indicate that, on the whole, 
errors in the arithmetic IPs, computed 
GOTOa and DO loops are not easily found 
with conventional test data seta, 

The third set are the relational operators 
and arithmetic IPs which determine the 
inclusive boundaries of the input data 
domains. These ate the relational operators 
involving equality, l.e. .EQ., ,NE., ,bE,, 


.GE. , and also the *ero case of the 
arithmetic IP, Results obtained for this 
subset lead to an average A3 ratio of 0,04 
(standard deviation 0.22) Cor the routines 
tested. Again the relatively high 
percentage of dead mutants in the 
Efllatlonal operators (approximately 65%) 
dominates the percentage of dead mutants in 
the arithmetic IPs (approximately 26%), This 
indicates that providing test data for 
these domain boundaries is not a common 
occurrence. 

From this work we can conclude that a 
limited mutation analysi-i, concentrating on 
particular subsets which demonstrate a 
specific testing strategy, is a worthwhile 
aetivUy. The cost of the exercise, being 
of the order of fifty tuns per numerical 
routine, is acceptable, although it must be 
noted that this cost rises if the Initial 
test data adequacy is low. Our experiments 
show that when mutants are dead the 
differences between correct and incorrect 
output tend to appear in the first 301 of 
the output. This possibly shows that 
testers tvnd to put special cases and other 
tricky data first and mote general cases 
last. The effect, however, is beneficial to 
an automatic comparator. With the provision 
of a speoialised mutation system a dramatic 
coat reduction can be obtained or a wider 
class of mutant be considered. 
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A COt'RSS OS' 'WTHEMATlrAt, SOnWARE 

A. K. Cline 

Vnlveraltv of Texas at Austin 

PurliiR the four aeadaiaie years ending In IR81, « one 
semester course In wnthemntieal software ccmstnictlon 
has heer offered hv the Cowouter Sciences Department 
St the I'nlversitv of Texas at Austin. Although orlg- 
Innllv offered at a graduate ioVel. a modified veralon 
has been offered three times for undergraduote students. 
Tltose electing the class include students Interested 
In scientific programming as a profeaslon as well as 
mathematical engineering • and science students who 
seek to Improve their programming skilla. 

Purpose! 

The course purposes are to aqunlnt studenta with 
advanced programming topics and the theorv of quality 
software construction and to allow studenta to gain 
practical experiance working on a group prelect 
involving organising, coding, and taaclng a package 
of mathematical software subprograms. 

Prerequisite! 

Students arc first required to have on interest in 
programming for technical applications. A basic 
knowledge of FORTRAN is assumed as well as mathe- 
matics at the calculus level. A course in numerical 
methods Is not required hut mav be so in the future 
since nmnv examples in the lectures on programming 
motliodologv require fnmlliaritv with basic numerical 
nlgorlthma such as Rausslan elimination and linear 
InterDolation. 

Text! 

The lecture siatcrial in the course has been obtained 
from Che author's experience and follows no published 
text. However, several short paperbacks are recom- 
mended for collateral reading! 

Ledgard, H. F. , Programming Proverbs for FORTRAN 
Programmers . Havdtin, 1975~' 

Kreitshorg, C. B, , and 3. Shnejderroan, The F.lements 
of FORTRAN Style , Harcouvt, brace, Jsvanovich, 
1972. 

Format! 

Until the final several weeks of the semester, the 
class meets three times per week for lectures. The 
lectures cover programming methodology and background 
material for the group project. These topics are 
described In greater detail below. Onlv occasional 
lectures are given at the end of the course as students 
complete their projects and meet Individually or in 
isroups with the Instructor for criticism of their work. 

Prior to the formation of the group, a short program- 
ming assignment is given to the class, This assign- 
ment has been the coding and teatlng of a simple 
module implementing a search in an ordered array. 

The algorithm suggested is a variant On binary search 
employing inverse linear interpolation. The purpose 
of this initial project is to gain experience on the 
local system (many students are new to file usage, 
editors, and interactive computing) and to give some 
indication of the students' relative programming 


capnbllttlea, Anotlier important Indication la how 
energetic (alternntivelv, how procrastinating) each 
student performs the nsBlgnmont. Although a grade 
on tills aaaignment la rot uaed In a final courae 
grade determination, the studenta' grades as Uell 
as tlm length of tjwe required to com|uet« the aaaign- 
ment are made puUiie, Students then organlre them- 
selves into three paraon groups. The performance tm 
the First asaignment has proved to he n ver« good 
predictor of a student's performance on the group 
project, and with this knowledge and the ahtlltv to 
form their own groupa, we have attempted to mlnlmixe 
the common problem in group projects! an imbalance 
of ottltude or abilities causes an imbalance In the 
work load, 

The group project uaed in all four offerings of the 
course has been that of interpolating dica specified 
on an irregular e,rid In the plane. The packages 
include modules to form a trlnngulatlon of the points 
in the plane nnc modules for interpolation based 
upon this trinnguik'tlon. Several almpllfylng nsBump- 
tlons are made to avoid overconCern with mathematical 
detalla of the algorithm as opposed to the software 
Implementation, These assumptions include ignoring 
the poaslbilitv of any coUnearitv of the points in 
the plane and, ‘.»r the purpose of the smooth Inter- 
polation, that first partnil derivative valuea are 
available from the user as well as function values. 
This project provides a good mix of mathematical 
and computec science problems. 


A purpose of the course being to gain experience in 
software construction, and not neeeasarily the research 
level discovery of new algorltjimsi students are given 
a design of the package and brief descriptions or 
the algorithms. It la felt that this slmulntea well 
tlie situation in which a programmer la Implamontlng 
the theory developed by another. It also allows 
lectures and class discussions on the ^ilgoritlims 
with respect to their qualities. 

A final examination is given with the intention of 
costing the lecture material on programming motliodo- 
logv which was not applied in the project. 

Lecture Topics: 

Initially a review of tlie usage of the local system 
is presented and a discussion of tlie project and 
the algorithms for its modules, Tlie vocabulary of 
quality of software is then described! applicability, 
usability, efflcloncv, clarity, portability, modifi- 
ability, modularity, and floxablllty, With each 
characteristic, examples arc given and the importance 
(or unimportance) of problem areas is considered. 

The area of portability la explored in detail. The 
methodology for the testing of software and the design 
of software receive several lectures apiece (and are 
applied to the project). Several lectures on clover 
programming practices (e.g. decomposition of workspace, 
portable handling of mathematical constants, nccions in 
error situations, timing of code) are given. Finally, 
several miscellaneous topics, are covered: a brief 
introduction to sclentlFle computer gi/apblcs Including 
the use of the NCAR graphics package, various approaches 
to software documentation, and the 1977 FORTRAN standard. 
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MOVING SOFTWARE SYSTEMS TO A MINICOMPUTER 

C. CIONI, A. MIOU, A. TRUFPI 
tBtituto di Analisi dci StAComl ed Informacicd 
Via Buonarroti IZ, 00185 ROMA (ITALY) 

In the last feu years a well shaped phenomenon has 
been observed in the computer field! the cost of soft- 
ware production and maintenance is very high respect 
to the total cost of a computing system and it is still 
.".rowing during this time, 

Therefore it seems to be approrpiate to use all the 
available software as much as possible respect to its 
portability, modularity and documentation. At the same 
time the new software is going to be designed and im- 
plemented according to the software engineering rules 
[ 1 , 2 ]. 

The use of a minicomputer, together with the decreasing 
use of time-sharing system on large computers, quite 
often presents the need to move software systems from 
a medium-large computer to a minicomputer, 

This operation involves quite expensive transformations 
on the available software, while the quality of the 
final result, as far as the efficiency is concerned, is 
not foreseen. 

In order to gain as much confidence tin possible in the 
transfering process an "a priori" analysis is necessary 
and helpfull. 

This paper actually presents the design and the imple- 
mentation of procedures which suppi.y informations on 
how to move software systeits to a given minicomputer. 

We will refer in this paper to software system organized 
as n library of programs, where a single program may 
also use other programs of the library as its subpro- 
grams, We call this organization System of Programs (SP) . 
Generally a SP can also be seen as a collection of se- 
veral moduli, each of which is itself a set of programs 
belonging to the library. If a modulus accomplishes a 
specific, well defined function, it is a subsystem of 
tiie given SP. We call this modulus Independent Subsystem 
(IS), 

Therefore if a SP is represented ns a tree an IS is a 
subtree of the given tree. 

If the SP has been designed to be quite flexible and 
portable there is the possibility for the user to define 
the dimensions of the current data. Therefore a variable 
storage space is associated to each SP, together with 
a fixed storage space which is used for the local va- 
riab-iii of the different programs. We denote the va- 
riable 'i'wS ■ by SPACE and the fixed space by LOCAL, 

In the iinlowing we will refer to SP implemented in 
a programming language that uses static memory al- 
location. For instance FORTRAN. 

Examples of SP to be considered are the symbolic and 
algebraic computation system SAC-1 [4,3] and the 
Harwell Subroutines Library [7]. Both these systems 
have been implemented in standard FORTRAN, they are 
portable, modular and very well documented, 

In order to make a SP running on a computer which 
has less memory respect to the computer which the 
given SP was built for, one of the following techni- 
ques could be Used: 

- overlay of programs 

- spliting of the SP into several IS 

- reduction of the maximum size for SPACE 

- programs segmentation. 


Actually these techniques may also be used all to- 
gether, or in any combination. 

For each SP wa have ro figure out the total amount 
of words 

M(SP) - COD(SP)+LO0AL(SP)+SP/.CE(SP) 

to put our SP on the given computer, where COD(SP) 
ia the number of words of the objert cede of SP. 

The quantity PIX(SP) - COD(SP)+L0CAL(SP) is fixed 
for the given SP, while SPACE(SP) is a variable 
quantity. 

If we want use an overlay techniques we also need 
the tree structure representing all the calling re- 
lations between subroutines of SP, and again the total 
amount of words. 

In general if M is the size of the given computer 
memory available to the SP we must check the quantity 

D - M - FIX<SI» 

In order to get all the need informations to test, we 
can certainly use the compiler of the SP implementa- 
tion language, for instance FORTRAN, available on 
the given computer. 

An automatic procedure has been designed to accomplish 
all the tests already described. 
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Tailoring Hathematical Software for the CRAY-l 

David S. Dodson 
John Gregg Lewis 
Uilliatn 6. Poole, Jr. 

Boeing Computer Services Company 
Seattle, Washington 


Any new computer brought into the stable of a major 
computer complex offers special challenges to those 
who are responsible for developing and maintaining 
large mathematical software libraries. If these 
libraries are expected to execute on several 
different computers, as they usually are, they 
should be portable. Unfortunately, portability is 
often in conflict with efficiency: portability 
dictates that code be common to several different 
computers while efficiency suggests tailoring code 
to the specifications of the individual computers. 

The CRAY-1 computer is especially challenging in 
terms of reconciling portability with efficiency. 
Hardware vector arithmetic instructions must be 
utilized to reap the benefits of highly efficient 
code on the CRAY-1. Standard FORTRAN codes will 
compile and execute on the CRAY-1 with little or no 
modification. The FORTRAN compiler, CFT, does an 
admirable Job of generating vector instructions for 
certain vector DO loops. In order to approach the 
maximum speed of the CRAY-1, it is necessary to 
rewrite some of the FORTRAN code and, often, to use 
the Cray Assembler Language (CAL). In order to 
approach the maximum speed of the computer for some 
problems, quite different algorithms must be 
considered. However, in this paper we assume that 
any required redesign has been accomplished. 

If the code in question is modular, it is often 
fairly easy to identify those parts which should be 
specially coded. The CFT compiler can identify 
which subroutines are requiring most of the CPU 
time. But an astute programmer is needed to locate 
the inner loops which are CPU-intensive and to 
rewrite the FORTRAN code or replace it with calls 
to CAL-coded subroutines and functions. It is at 
this stage that the code starts to take on a flavor 
which is unique to the CRAY-1. 

Boeing Computer Services offers mathematical 
software libraries which are portable, modular and 
efficient. The primary library, BCSLIB, is 
available on at least 6 different mainframe 
computers including the CRAY-1. Several additional 
libraries also are maintained. T‘’e authors are 
involved in the development of library modules 
which are specifically designed for the CRAY-1, 


This paper contains an overview of their 
experiences at tailoring lutheMatical software for 
the CRAY-1. 

There are two fundamental ideas for making 
effective use of the CRAY-1 arithmetic hardware. 
First, the operands and results in the innermost 
loops should be structured into vectors and the 
computations should be vector-vector or vector- 
scalar operations such as adding two vectors or 
multiplying a vector by a scalar. Second, as many 
as possible of the CRAY-l's independent functional 
units should be brought to bear on the problem 
simultaneously. At the FORTRAN level, little can 
be done to promote a high level of concurrency. 
Frequently, astounding performance gains can be 
realized by using general purpose CAL-coded 
routines such as the BLAS, or by developing 
special-purpose CAL routines. 

The first step in this project was to determine a 
priority of tasks based on two considerations: 
what basic numerical problems are most frequently 
encountered in large-scale scientific computing, 
and which problems are most amenable to CRAY-1 
vectorization? Our first efforts were oriented 
toward linear algebra problems because they are 
often the Innermost computations of many 
mathematical models. Furthermore, they are 
problems for which vector arithmetic instructions 
can be readily utilized. 

Me have implemented and evaluated several 
fundamental linear algebra subprograms, including 
the BLAS package, several versions of LINPACK and 
EISPACK, several versions of SPARSPAK, and we have 
worked with several application codes which have 
sparse matrix computations in their innermost 
parts. For example, we considered four vjrsions of 
LINPACK: the standard FORTRAN version from Argonne 
National Laboratory, the version provided by Cray 
Research Inc. with FORTRAN and some CAL, the 
standard FORTRAN version but with calls to CAL BLAS 
provided by Cray Research Inc, (CRI), and the 
standard FORTRAN version with calls to CAL BLAS 
produced by one of the authors. A brief summary of 
our results follows, 

0 The CAL-coded versions of the real, single 
precision BLAS, supplied by CRI as part of their 
SCILIB scientific applications package, were 
enhanced, yielding increases in execution speed of 
10< to 25X. For example our version of SNRM2 can 
execute at an asymptotic rate of 140 megaflops 
compared to the SCILIB version of SNRM2 which 
executes at an asymptotic rate of 113 megaflops. 
For comparison a CFT-compiled version of SNRM2 
achieves an asymptotic rate of about 36 megaflops. 
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0 The SCILIB version of UNPACK differs from the 
standard version In modifications of code which are 
better suited for the FORTRAN compiler and In the 
use of some CAL BIAS. The SCILIB version of SGEFA, 
an Important LINPACK routine, executes In about one 
third the time required by the standard FORTRAN 
version. The version using locally developed BLAS 
(Outperforms the SCILIB version for matrices larger 
than 200x200, 

0 Minor modifications to EISPACK to aid the CFT 
vectorizer and to use the BLAS have dramatic 
effects on some eigenvalue paths. Throughout 
EISPACK, the execution rates are degraded 
considerably for two-dimensional matrices whose 
leading dimension Is a multiple of eight. The 
degradation Is due to memory bank conflicts. 

0 Speedups of lOX to TOOK over standard FORTRAN 
codes can be achieved In sparse matrix 
factorizations even with little or no 
vectorizatlon. We achieved such speedups both for 
problems held In envelope (variable band) format 
and also for more general and compact storage 
schemes. These Improvements were achieved by 
replacing some of the Innermost loops of key 
SPARSPAK routines with calls to CAL-coded routines. 

In summary, the authors have found that significant 
speedups can be achieved by tailoring mathematical 
software to the CRAY-1 's specifications. This can 
be done without affecting the user's program by 
changing only basic building block routines such as 
those In the BLAS, LINPACK, EISPACK, SPARSPAK and 
other frequently used packages. This approach also 
achieves a high Ctegree of portability since the 
basic tools used all have portable FORTRAN 
equivalents. 


FLEXIBILITY IN MATHEMATICAL SOFTWARE 
DEVELOPMENT USING OPTION ARRAYS 

by R. J. Hanson 
Sandla National Laboratories 

F. T. Krogh 

Jet Propulsion Laboratory 


Introduction 

Mathematical software (any type of software for 
that matter) has at least two goals. It should 
be easy to use. It should also be flexible and 
broad in Its problem scope and thus satisfy a 
large number of the possible users of this soft- 
ware. These goals conflict with each other. It 
Is the purpose of this paper to suggest some ways 
to reconcile this conflict by use of so-called 
“option arrays." 

The methods we are proposing for the "option 
array" specifications are general. The Imple- 
mentation that we illustrate with an example Is 
presented in FORTRAN, but the extension to other 
programming languages is obvious. 


With any of the subprogramt, say SUBPR (j) , 
there will be H(J) options that the user can 
change. The author makes a numberei. list of 
options for each subprogram, describing the fea- 
tures and usage of each of them, 


An Example to Illustcate the ideas 


Solving dense systems of linear algebraic equa- 
tions Is a process chat has received much atten- 
tion from software specialists, Ref. (1). To Il- 
lustrate the techniques ue propose we'll present 
the design of the options and a sample usage of 
a (mythical) subprogram for solving linear alge- 
braic equations Ax*b, A ■ N by N real matrix. 
ThiO design Is for Illustration only; a non- 
trivial real example Is given in [2], 

The nominal usage (no options) solves a system 
of equations with a single right-side vector. 
This usage Involves the usual dimensioning of 
the required arrays, the definition of data, 
and Che subprogram CALL statement. 


Nominal Usage; 

DIMENSION W(MDW,N+1), lOPT(l), ROPT(l), 

SIWORK(N) 

(Define matrix laio] within artny W (*,*),) 
I0PT(l)-99 

CALL SLl (W,MDW,N,I0PT,R0PT,1W0RK) 

(The solution vector, x, la returned in the 
array W(*,N+1).) 

This subroutine looks simple to use and narrow 
In scope. But now we have a (rare) user who 
wants to do a relcted computation: 

1. There is no system to solve. 

2. The determinant of A is desired. 

The subprogram package author has provided a 
number of options In the subprograms that allow 
these related casks to be done. The linear 
equation software Involves suuprograms SL1( ) 
and SL2( ). The subprogram SH( ) calls SL2( ) 
to perform Gaussian elimination with partial pi- 
voting. The subprogram SL1( ) Is called by the 
user. 


Option List for SLl ( ) 


Option Number 


Solve Ax-b with k ^ 0 1 

right-side vectors; k»l Is 
nominal. 


Solve (transpose of A)y-c 2 

with m >.0 right-side 

vectors. 


Do not decompose the matrix A; 3 
this has already been done. 
Nominally the matrix A Is 
decomposed each time SLl ( ) 

Is called. 


Provide an option array to A 

SL2 ( );' nominally no option 
array is provided to SL2 ( ). 
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Optloa Litt for SL2 ( ) Option NUnber 

Provldt column icallng 1 

for the matrix A. 

Compute the determinant of 2 

A in the form det (A) • 
a * exp(t). Provide the 
parametera a and t aa 
output valuea. 

TMn't redxcompoae the matrix 3 

A; thia haa already been donei 
Nominally the matrix A la 
decompoaed each tine SL2 ( ) 
ia called* 

We'll now give the values for the option array 
lOPT(a) that 1.) reset the number of right aides 
to aero, and 2.) compute the determinant of A in 
the form mentioned above. Comments in the right 
margin clarify the meaning of each entry. Note 
that the processing for the option arrays is 
terminated with the reserved option number, 99. 


Optional Usage t 

dimension W(MDH,N), I0pT(8), R0PT(2), IWORK <N) 
(Define matrix A within array W(*,a).) 


lOPT(Ol) 

I0PT(02) 
IOPT(03) 
IOPI(04) 
IOPTC05) 
I0PT(06) 
I0PT(07) 
I0PT( 08) 
CALL SLl 


» 1 (Option number for SL1( ) to 

change number of right-side 
vectors.) 

» 0 (The number of right-side 
vectors.) 

» 4 (Option number for providing 
an option array to SL2( ).) 

- 6 (Pointer to start of option 

array for SL2( ).) 

» 99 (No more options for SL1( ) 
remain. ) 

■ 2 (Option number for SL2( ) to 

compute the determinant of A.) 

- 1 (Store a in ROPT(l) and t in 

the following location.) 

» 99 (No more options for SL2 ( ) 
remain). 

(W,MDW,N, lOPT.ROPT, IWORK) 


suits with the new version, and with the addition 
,of the description for the new option, the old 
documentation still applied. 
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The determinant of A is available In the form 
det(A)-R0PT(l)*EXP(R0PT(2,)) after the return from 
subprogram SL1( ). 

Ideas similar to those presented here are used 
in [2] and In some of the software In the 
libraries [3] and [4J. 

There have been a few important applications 
where the added flexibility provided by options 
within the software has saved expensive modifica- 
tions to existing code. The effect of this has 
been to save the authors' time and the time of 
the user while a new programming effort was made. 
Another significant saying in time that prevented 
complications for several library users was real- 
ized by Krogh. The existing nonlinear least 
squares subprogram of Ref. [4] was modified to 
provide for simple bounds on the unknowns. This 
change was made using a new option number. Users 
of the previous version of the non-linear least 
squares subprogram continued to get the same re- 


Thc Pnbltai 

The production and maintenance of complex computer programs 
involves an enormous amount of bookkeeping. First, there may be 
a multiple Versions for different reasons; 

During development, errors will be corrected, facilities will be 
added or deleted, or there may be changes of implemenUtion 
strategy. 

A program may be made up of almost independent parts, and 
different subsets of tbe collection may be provided to different 
users. 

The same functionality may be provided in more than one 
environment (different hardware, operating system, or 
language) 

A particular version of a program is specified by a set of daui and a 
set of processing steps to be performed. Some of the data will be 
fundamental (cannot be recreated automatically), such as program 
source text entered by humans and daU produced by the real world. 
Other data can be derived, and sometimes stored, by reproducible 
processing steps applied to fundamental data and already derived 
data. The derived data may be used for other purposes such as 
debugging, producing listings, or running the program, 
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K«*fi<n| Inck of Ike prpceuiiii uepe and the •late of tke compata* 
lioa caa be a ai^ kaadackc. Operalioai aiail be perforaied ia a 
fiacd order «dlk coaiplicaled artamealt aad opiioa ipaciloatioai, 
eiTon aiail be coaiidcred, aad records aialaisiaed. la aiaiple 
caHi, the procctiiap ii clear, 'raa Ike decki lkro.ii(h Ike Fortran 
compiler aad eiccule Ike re>allia| propram*. But lack > detcHp. 
tioa {• oftea aot appiiaMe for iipaiRcaal jobt; librarici miiil to be 
eMablUbed aad apdaled, loarce Mae awy be proccMcd by a 
lequcace of proprame (macro proceteore, laapuape (raaelatore), a 
liaMe iource Me may participate la more lhaa one compilalioa, aad 
a liaple compilalioa auy lavolve more than one iohkc Me (ai In 
lanpvapci that permit 'inclade Mea*). The proccieinp itepe are 
likely to be limilar for dlflcrent vereloat, but with imall but eiien- 
tial diflcrencea. Rememberinp the aequence of operationa to be 
performed ia likely to be a aipaifiGant taaki kceplnp track of the 
•late of intermediate Mea ia even harder and more error-prone. If 
more than one perron ia Invsived in the conatruction or 
maintenance, they muat communicate and avoid inconaialency in a 
diaciplined way, 

Tealinp and veriScalioB alao bep to be oipaniacd. Simply makinp a 
chanpe, runninp a aimple teal caac, then inatallinp the repaired ver- 
•ion often aucceeda, but ia unaatiafaciory once there are uaera who 
are remote or who depend on your propram. It ia important to 
maintain repreaaion teat auilea, eataUiah that all the propram 
branchea have been eaeiciaed, and check that the reaulla are 
correct, or at leaat aufflciently accurate. The problem ia appravaled 
if veraiona are beinp mainlined for environmenta which are not 
immediately acccaaiUe. 

AaacllarallBp Appawatehae 

The waya to attack there proUema may be viewed aa a aequence of 
levela, at each of which the proprammer aurrendera aome control to 
the computer in eachanpe for havinp the machine’a increaaed aaaia- 
tance. All are baaed on an orpanized Minp ayatem. At Aral, thia 
filinp ayatem mipht be a notebook full of penciled notationa about 
bup fixea, ebanpea for different veraiona, tape reel numbera, and 
Job control aequences, It ia amazinp how far one can po with the 
manual approach, but eventually the notebook becomea illcpible, 
diaappeara into a collaborator'a office, or auffera aome other diamal 
fate. 

The obvioua alep ia to atore the notebook in a computer where It 
can be protected apainat decay. The propram aource will alao prob- 
ably be kept in computer filea aince text editora permit eaay entry 
and modification. The notebook can contain Me namea Inatead of 
propram deacripliona. It ia eaay to capture frequent inputa (e.p., 
canned command aequencea that can be iaaued without rely^np) 
and outpula (e.p., aucceaaful teat resulla to compare apainat new 
runa). if aeveral people are workinp on the aame project, the cen- 
tral file ayatem can be uaed to coordinate and ahsrs the work and to 
communicate propreaa and problema. At thia level, the coinputsr ia 
beinp uaed in a diatant way: it atorea data, but doea not poide the 
work. 

At the next level, one takea advantape of the airucture of the com- 
putinp ayatem. If the Me ayatem permita hnp namea or haa a 
hierarchical orpanization, related forma of a file can be atored in 
Mea with computable namea. If auch a naminp diacipline it fol- 
lowed, production of veraiona can be automated by parametrizinp 
tome of the commanda or by uae of acceatinp functiona. For 
example, Carpiil ahowed how complicated aela of alternativea can 
be handled by diaciplined uae of the Me ayatem hierarchy. 

The file ayatem probably maintaina certain uaeful information; 
namea and lenptha of Mea, perhapa their type (aource, object, 
library, etc.), and the time the file waa laat chanped. Such informa- 
tion ia reliable, free, and can be extremely uaeful. For example, a 
propram can make mapically accurate deductiona without explicit 
inatruction; if the reault of a compilation ia needed, and if a rource 
file that waa edited aince the laat compilation waa completed, then it 


(a probably a^oprialc to raconipile ikt aource, A program can 
aukc thia daductioB and laaue commanda to the ayatem with little 
iaiervenlion or tkoupht by a kuaMB, (My Make program doea 
ikia), Tkia approach ia indepeadeal of the deialla or content of the 
Met, and only nceda to know Ike ute of the Me, which ia deduciMe 
from the name or ottributei on many ayatemt, ac 1 when it waa laat 
chanped. At Ikii tugc of mechaaiaatioa, Ike r andard computer 
ayatem It beinp uaed in a direct wa.-; the uter maintaina hit own 
Met for bit commanda, veraiona of aource, propreaa atatua, and ao 
on, and invoket Ulilitica explicitly. 

If more help ia needed or deaired, the computer muat be involved 
more intimately, Tke baaic data arc controlled ^ the computer, 
and may be atored in unreadable forma. Varioua veraiona may be 
intertwined for reatont of control or efficient, and can only be 
examined ihrouph the toolt. Thuc, the SCCSi ayatem atorea many 
veraiona of a text in a form that aavea tpw;e, but explicit SCCS 
commanda are needed to extrtuH an old veriJon or to atore a new 
one, Toolt at thia level may alto attitl in nanaginp the project by 
rcatrictinp occett to programt, preventing multiple updtiet, and 
requiring explanationt of the work done before accepting a new 
vertion. Note that Ihcte effoitt have been bated on a coarte unit 
of operation, the complete data Me. 

Finally, we reach the level of to-called program environmenta, 
which take over many of the operationa done by proprammert. In 
exchange for the convenience offered by the ayatem, the program- 
mer muat cccept ita reatrictiona. Tbit ia at*, area of active reaearch; 
aome efforta in thia area are Inicriitp, Gxndalf, Mentor, and Tool- 
pack. The baaic form of the fundamentai data can be aource text or 
a parted repreaentation. The divitiott of reapontibility among toolt 
may then be radically different than in a conventional ayatem. 
Some of the toolt may be invoked inviaibly. Editora, printera, and 
compilert make ute of the tingle baaic repreaentation, An editor 
can check propram ayntax, and a compiler can be invoked automati- 
cally after an edit it complete. Maintaining atatem enl Utope counit 
and timing analytet can be implicit in the compilation procett, 
Tealinp and debugging an be done in termi of the uter’t aource 
language, without reference to machine-level objscta. and teat data 
mipht be taved aemi-automalically. In exchange for Ihete tervicet, 
the uter annot apply tiandard toolt to the data, aince they are 
encoded and the environment mutt control all chanpea that are 
made. 

A well-informed environment an control large objecta auch at 
libraries or executable programt, and an enture that veraiona 
remain in parallel. The environment could produce inatrumented 
forma of programt to monitor the teatinp; the inatrumentation 
could record the tialemenit that have been executed and the atate- 
menta that contumed moat of the machine time, The environment 
an alto re-run reprettion leata before inatallinp or diatributinp final 
copiet, and maintain recordt on veraiona that have been tent nut, 

Applicabllily to Nnmcrical Programa 

The aimpler approachet ditcutted above an all be applied to 
numerial programt on any flexible ayatem. The more complete 
ayatemt require tome tailoring to the language and habita of the 
proprammert. The propram environmenta currently available are 
all reaearch toola deaipned around lanpuopea that are rarely uaed for 
numenal programming. The proMeiha ot preproceatora, naminp 
conventiona, and enormout libiuiea require special ccnr>deration. 
The floating point domain priaenta tome peculiar difficulliet; a 
reprettion teat may be required to achieve final reaulta of aatiafac- 
tory precision, but not necettarily to duplicate the previous run’s 
output bit for bit, or even to produce comparaUe amountt of out- 
put. (Consider a chanpe to an iterative algorithm which chanpea 
the number of iterationa to produce aatiafactory convergence). 
Varioua projecta are underway to attack aome of theae problema. In 
particular, the Toolpack projM ia deaipninp a portable environme.> > 
for Fortran-baaed programa. 


IA. Calil 
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